How we modernized the portal yota.ru

Some time ago we completely redid the portal www.yota.ru. Despite some continuity with respect to the previous version, the site was almost completely redone - both the front-end and back-end. The need for this large-scale modernization has finally matured, as soon as Yota began to provide services as a mobile operator. Below we want to tell why it was necessary to redo the site, what tasks we solved, what difficulties we faced and what we have achieved at the moment.

The reasons for upgrading the site and the subsequent decisions can be divided into two groups: related to the front-end (design, site map, page structure) and back-end. Consider each of them separately.

Front-end: design and structure

Until August 2014, Yota provided services in the field of wireless 4G Internet, and the functionality and capabilities of the portal met the needs of our users. But with the transition of Yota to the status of a mobile operator, new requirements began to be imposed on the site.
')
It is worth saying that the Yota offer is different from what is present in the mobile market today. And since our portal is not just an information resource, but an important tool for interacting with users, designed to independently manage all services, it first of all should have reflected the changes that have occurred with Yota. And not only the design was to be changed.

With the expansion of the range of services navigation on the site is difficult. According to the results of our usability testing, it turned out that in order to obtain the necessary information, users had to perform quite a lot of unnecessary movements. The elements and blocks were not sufficiently obvious and logical, so that on the way to the goal the site visitor made more clicks - for example, to select your city and see the coverage map.

The second important reason for the alteration of the front-end was the lack of reserves for the scalability of the internal structure. With the advent of new services and the expansion of the geography of our presence, we are faced with the fact that without altering the very structure of the site, expanding its content becomes extremely difficult. Yes, and it looked not too good.

Before starting work on a new design, we conducted a study of the target audience. Obviously, when designing the new site, we were limited to certain style requirements: it was necessary to use existing corporate colors and headsets. In addition, the design of the site had to carry absolutely clear messages: we are not like other operators and our services are very easy to use.

From the point of view of the site structure, it was necessary to solve the following problem. Up to 70% of users get to the portal through the main page. And it was important for us to make sure that they either could find the necessary information right here, or in one click go to the section of interest. For example, one of the main questions before buying a wireless modem: “Do I have network coverage at home / in the office?” Therefore, we gave the opportunity to find out about it with one click on the main page.

Another important point was connected with the main page of the previous version of the portal. About 25% of users from those who went to the home, then just left the site. For a long time we could not identify the reason for this behavior. The UX testing conducted during the development showed that some users simply do not want to navigate the site menu. The need to understand, search for the necessary link, click on it was perceived as excessive complexity of the site. As soon as we placed on the main page a module for ordering modems and SIM-cards, the number of “refusers” sharply decreased.

During UX testing, we also tested the effectiveness of various controls on the page. In addition to many interesting points, it turned out that users began to double-click on buttons when we increased them 1.5 times compared with the previous version of the portal.

Back-end: site platform

The development of the new portal led to the change of the platform on which the site was based. The CMS Bitrix used at that time did not satisfy all our requirements, since:

• The system had a nonclustered configuration, that is, the entire load on the site fell on a single PHP server. Its productivity resources were almost exhausted, there were cases of site overload and inaccessibility. And the transition to the version of Bitrix, which supported clustering, meant a significant reworking of the code.
• All content updates were made immediately on the working server, and in the event of any errors, this was reflected in the performance of the site. That is, it was necessary to reduce its accident rate, thereby improving the quality of service to our users.
• The system did not use the CMS Bitrix capabilities for self-editing of content by employees of the company's business units. All changes needed to be made using manual editing of certain files, and this responsibility rested with programmers supporting Bitrix and IT staff. This meant additional costs of resources, distraction of IT-specialists from the tasks of support and maintenance of infrastructure, etc. By the time of transfer of site management to the IT department, this method of management has completely exhausted itself. The time has come to relieve technical specialists from the obligation to fill and update content on the site. It was necessary to design and implement such a solution that would maximize the use of CMS capabilities to reduce costs and content editing time, ensure high availability and performance with minimal maintenance costs.

An analysis was made of the possibility of further development of Bitrix, taking into account all our needs. This path was recognized as inexpedient, since the migration would have been significantly complicated: for clustering, it was necessary to upgrade Bitrix version, buy modules, rework a significant part of the code. In the end, we would not get as many content management opportunities as we wanted. That is, technicians would still have to perform a lot of non-core work, which in the case of other systems can be transferred to the relevant business units of the company. And accessibility issues related to architecture and technical support.

So, being faced with a choice - try to bring Bitrix to mind or introduce a new CMS - we chose a new one. The matter remained for small: to decide on a specific system. Various proposals were considered, ranging from proprietary proprietary products, followed by complete dependence on solution providers, to writing a system in Ruby from scratch, with all the attendant risks, unknown performance, functionality, and unsatisfactory support.

As a result, the choice was made in favor of the Liferay system. This platform offers quite rich and flexible functionality, which will be discussed later. One of the significant advantages was the openness of the system: in most cases, our company relies on open source technologies, since this makes it possible not only to control the operation and functionality of the products, but also independently to perform flexible configuration to suit your needs. It is impossible not to note such advantages of Liferay as homogeneity with our other systems and technologies (we mainly use JEE technology) and ease of maintenance. Including due to the fact that when deploying Liferay we were able to make the most of the existing infrastructure - operating systems, application server, database - the implementation of Liferay did not put forward any specific requirements for the environment.

For the new configuration, which is capable of painless scaling in the future, the following scheme was adopted: two servers in active cluster mode (that is, both devices are active) service the site itself and requests to it. A separate server is assigned the task of content management. That is, there is an active backup of the servers of the site itself, and the server with which employees of different Yota departments work, integrated with our authentication system, is hidden in our corporate subnet.
To improve performance, we used a well-known solution for high-performance applications: we implemented the CDN (content delivery network) model, installing a number of Nginx servers containing graphic files, text files, CSS files, etc. on the site. Thus, we completely removed the load on the release of static content from the site servers. This solution also simplifies the subsequent scaling, since the number of Nginx servers can be increased many times as the load increases.



The content manager server performs a kind of buffer role, a pre-moderation tool. For example, if an employee of a department wants to publish news or other information on the site, the data is sent to the content manager's server, where they must be approved by the head of that employee. All these workflows, workflow, can be flexibly configured using the integrated BPMN editor - Activiti. After approval of the content it is published on the site. This procedure can be carried out either manually by the administrator, or automatically, including on a schedule. For example, at night, when attendance is minimal. Such a scheme of work - staging, that is, a breakdown into stages - allowed to manage content changes and prevent accidents. Now you can test all the changes made without uploading to the site.

Another advantage of Liferay in terms of content editing is the ideology of WYSIWYG (what you see is what you get). That is, all changes are made not in the program code, but using a convenient graphical interface. An employee with administrative rights opens a copy of the site in the browser on the CMS server, moves the mouse and adds the necessary elements, directly makes changes to the text, then confirms the changes and can immediately see what the site will look like for users. This allows you to avoid typos and errors in the layout in the working version of the site.

A separate task was the organization of the end-to-end development process and modifications of our site from designers to the launch of changes on the site. The Yota site (as well as the company itself) is developing very dynamically - we are constantly engaged in its improvements, and here it was very important to make the process of implementing new ideas as fast as possible. We managed to adjust the work of several teams so that the path from the “idea” to the site began to take a minimum of time. The basis of this is: a permanent build over the development / test / delivery branches (Git, Grunt, a set of pre-processors), as well as the standard for the implementation of the layout, which reflects such rules as: one common for the site minified CSS and specialized CSS, no mixing of functional styles; ban iFrame, placing hashtags in containers, etc.

Many Liferay developers face the challenge of integrating JavaScript into portlets. Before us, it also arose, and we found the following solution, reflecting in the development standard: prohibiting global variables, use backbone.js to manage dependencies between modules, system.js, to connect modules; All parameters of the JS module are set through the designer (including localized text resources, DOM element selectors, request parameters to the back-end REST API), which the portal initializes when the portlet is rendered; the constructor also provides default call parameters; JavaScript component interaction via jQuery.

On this we, perhaps, emerge from the technical depths and try to summarize.

results

For the end user, the most visible result of our work was the change in the design and structure of the page. The performance of the front-end has grown, not least due to the removal of statics on separate servers. At the same time, clustering and implementation of statics servers made it possible to exclude the possibility of accidents during high load hours. Even in high traffic conditions, the site does not reduce its performance.

From the point of view of the Yota employees who make changes on the site, this procedure has been radically simplified, appeared:

• WYSIWYG-editor that allows you to change the structure of the site without the participation of programmers;
• access to content for employees of any departments;
• implementation of the approval process for changes;
• fully controlled publication process on the site.

Currently, we use no more than 20-30% of Liferay's capabilities, both in terms of functionality and performance. Therefore, the modernization of the back-end can not be viewed as a solution to only immediate needs. This was a strategic step that in the future will allow solving new tasks faster and more efficiently, both for new functions of the site and for expanding the possibilities of customer self-service.