JavaScript API Yandex.Maps - version 2.1-beta - new design and new features
We have released the beta version of the Yandex.Maps API 2.1 . Its main feature is a complete redesign of the map interface. Moreover, the changes affected not only the appearance, but also the behavior of the map controls. Since it was initially clear that backwards-compatibility failures cannot be avoided, we also made architectural changes that were necessary to improve the work of the API (about them closer to the end of the post).
As for the design, it was important for us that the interface looked equally well on devices and screens of different sizes. One of the main difficulties is that we never know in advance what the service or website with embedded maps will look like. Therefore, when developing a redesign, we had to try to provide a maximum of options.
To solve our problems, we decided to implement an adaptive interface design in the new version. At the Yet Another Conference, madhare designer and zloylos developer gave a talk about why we needed adaptability and how exactly we implemented it in the API . In this post, I will describe the background and the concept of our decisions, talk about what's new in version 2.1-beta, and what else will change to release 2.1.
After the release of version 2.0, we already wrote a post in which we talked about our approach to API development. The essence of the concept is that we make the product not only for developers, but also for those who will enjoy the results of their work. If a person is comfortable and pleasant to use our cards, and he will require them from his favorite services - this will be a real success. At the same time, developers should also be easy and pleasant to satisfy the desires of users, which means we should simplify their work with the API to the maximum. With such thoughts, we began work on version 2.0, and the new 2.1-beta was a logical continuation of the same concept.
Observing the installation of our API and analyzing the cases of using maps, we identified two main types of developers:
So, we had to do well first, leaving second room for maneuver. Those. prepare a set of ready-made solutions that themselves control the appearance of the final map, i.e. “They do well”, but at the same time, if desired, they can be customized for their own needs. The task of the maximum was to maintain a balance.
')
Having decided on the audience, we began to study use cases. It turned out that in our case, the main meaning, oddly enough, size. We got 3 + 1 options: small, medium, large map and mobile sites.
The worst case is small cards. It seems that because of the small size it is worth removing all the controls of the card, but I also do not want to lose functionality. Therefore, we made a new set of controls especially for small cards:
A new control has also been added - “expand the map to full screen”. It saves space on the site by placing a small card, while the end user is left with the opportunity to see a large map. All the necessary behavior of the card is already programmed on the API side. In general, the idea of ​​this button was born when we thought about a solution for mobile devices. An acceptable size card on the desktop can become completely useless on your mobile. Fulskrin solves this problem:
In addition, the balun design has changed for small-sized maps. Now on small maps and mobile devices, the standard balloon is replaced with a die at the bottom of the screen. This allows you to save more information card for users. If desired, this option can be disabled.
With average cards, everything is much simpler. Since there is where to turn:
As with the big cards:
In order to simplify the work of developers as much as possible when selecting map controls, we made three ready sets for different map sizes.
List of available keys:
smallMapDefaultSet // for small
mediumMapDefaultSet // for normal
largeMapDefaultSet // for large
Of course, you can still specify the necessary controls by yourself.
It is not enough just to draw an interface design for different card sizes. After all, a page with a map can be opened on different screens. That is why it was decided to implement the adaptive behavior of the card interfaces. Different interface elements are rebuilt and change their size depending on the actual size of the map container.
We implemented adaptive behavior through control.Manager . You can also set it for those buttons and lists that you create yourself:
A geoobject is the main entity on the map. For such a title he has to pay a rather complicated and cumbersome structure. The first iteration of work on geo-objects was to distribute the load during their creation. We tried to bring all the preparatory operations from the constructor of the geoobject to the places where they really become necessary. It gave very good results. Also in some places we made lazy initialization of entities using _defineGetter_ and defineProperty (_defineGetter_, by the way, a bit faster). We have reduced the number of subscriptions to geo-objects events within our system of events. Partially helped by accepting a subscription directly to a group of geo-objects with the subsequent definition in the handler of the target object. Here you have to admit that acceleration can only be felt on dom and canvas tags, new svg tags should be modified (why we call it beta? Because it beta then nothing;)
While working, we had time for a small cleanup in the code, according to its results we will give microvirculation:
Microdraw 1. When transferring a handler function, it is much more advantageous to transfer the function separately, the context separately. If your hands are itching to do a bind right away, consider whether you can afford it.
Microdraw 2. Reduce the number of intermediate arrays, objects, and anonymous functions. They are not always well cleaned by garbage collector.
The API 2.1-beta API reference guide is published on the API website . Examples can be found in the sandbox . And also the beta version of Yandex.Map is already working on the new API.
As for the design, it was important for us that the interface looked equally well on devices and screens of different sizes. One of the main difficulties is that we never know in advance what the service or website with embedded maps will look like. Therefore, when developing a redesign, we had to try to provide a maximum of options.
To solve our problems, we decided to implement an adaptive interface design in the new version. At the Yet Another Conference, madhare designer and zloylos developer gave a talk about why we needed adaptability and how exactly we implemented it in the API . In this post, I will describe the background and the concept of our decisions, talk about what's new in version 2.1-beta, and what else will change to release 2.1.
Why do we think about design?
After the release of version 2.0, we already wrote a post in which we talked about our approach to API development. The essence of the concept is that we make the product not only for developers, but also for those who will enjoy the results of their work. If a person is comfortable and pleasant to use our cards, and he will require them from his favorite services - this will be a real success. At the same time, developers should also be easy and pleasant to satisfy the desires of users, which means we should simplify their work with the API to the maximum. With such thoughts, we began work on version 2.0, and the new 2.1-beta was a logical continuation of the same concept.
Study
Observing the installation of our API and analyzing the cases of using maps, we identified two main types of developers:
- They solve typical tasks, do not want to spend a lot of time, prefer ready-made Yandex interfaces. About 90%.
- Solve non-standard problems or prefer even typical tasks to solve in their own way. They are not suitable standard controls. Need serious customization of maps. It is logical that this is the remaining 10%.
So, we had to do well first, leaving second room for maneuver. Those. prepare a set of ready-made solutions that themselves control the appearance of the final map, i.e. “They do well”, but at the same time, if desired, they can be customized for their own needs. The task of the maximum was to maintain a balance.
')
Having decided on the audience, we began to study use cases. It turned out that in our case, the main meaning, oddly enough, size. We got 3 + 1 options: small, medium, large map and mobile sites.
Draw design for maps of different sizes
The worst case is small cards. It seems that because of the small size it is worth removing all the controls of the card, but I also do not want to lose functionality. Therefore, we made a new set of controls especially for small cards:
A new control has also been added - “expand the map to full screen”. It saves space on the site by placing a small card, while the end user is left with the opportunity to see a large map. All the necessary behavior of the card is already programmed on the API side. In general, the idea of ​​this button was born when we thought about a solution for mobile devices. An acceptable size card on the desktop can become completely useless on your mobile. Fulskrin solves this problem:
In addition, the balun design has changed for small-sized maps. Now on small maps and mobile devices, the standard balloon is replaced with a die at the bottom of the screen. This allows you to save more information card for users. If desired, this option can be disabled.
With average cards, everything is much simpler. Since there is where to turn:
As with the big cards:
In order to simplify the work of developers as much as possible when selecting map controls, we made three ready sets for different map sizes.
map.controls.add('default'); List of available keys:
smallMapDefaultSet // for small
mediumMapDefaultSet // for normal
largeMapDefaultSet // for large
Of course, you can still specify the necessary controls by yourself.
myMap.controls .add('trafficControl') // .add('searchControl') // .add('zoomControl') // - .add('typeSelector') // .add('geolocationControl') // .add('fullscreenControl') // …
Adaptability
It is not enough just to draw an interface design for different card sizes. After all, a page with a map can be opened on different screens. That is why it was decided to implement the adaptive behavior of the card interfaces. Different interface elements are rebuilt and change their size depending on the actual size of the map container.
We implemented adaptive behavior through control.Manager . You can also set it for those buttons and lists that you create yourself:
Acceleration and optimization work
A geoobject is the main entity on the map. For such a title he has to pay a rather complicated and cumbersome structure. The first iteration of work on geo-objects was to distribute the load during their creation. We tried to bring all the preparatory operations from the constructor of the geoobject to the places where they really become necessary. It gave very good results. Also in some places we made lazy initialization of entities using _defineGetter_ and defineProperty (_defineGetter_, by the way, a bit faster). We have reduced the number of subscriptions to geo-objects events within our system of events. Partially helped by accepting a subscription directly to a group of geo-objects with the subsequent definition in the handler of the target object. Here you have to admit that acceleration can only be felt on dom and canvas tags, new svg tags should be modified (why we call it beta? Because it beta then nothing;)
While working, we had time for a small cleanup in the code, according to its results we will give microvirculation:
Microdraw 1. When transferring a handler function, it is much more advantageous to transfer the function separately, the context separately. If your hands are itching to do a bind right away, consider whether you can afford it.
Microdraw 2. Reduce the number of intermediate arrays, objects, and anonymous functions. They are not always well cleaned by garbage collector.
Other changes
- In API 2.0, to locate by IP or using the Geolocation API, developers have to independently use the necessary methods and process the result. In version 2.1, simply add a new standard control:
The user location mechanism used in the API has also been improved. Now the most accurate result is automatically selected from browser geolocation and geolocation by IP address.control.GeolocationControl(parameters) - Standard labels in the API were redrawn in SVG, which means that they can be given arbitrary colors.
- The package system in version 2.1 will be eliminated. APIs are modified in such a way as to maximize the load on the components of the API on demand, for which most of the mappings were transferred to asynchronous mode. Work is still underway.
- For such a massive update, we had to sacrifice backward compatibility with version 2.0. Also, for the official release of version 2.1, backward compatibility for some parts of the beta version may break:
- The clusteriser will change significantly.
- Map.action.Manager will be rewritten.
- Promises will be implemented according to the DOM specification .
- Some of the objects in the ymaps namespace will be put into on-demand download.
- After exiting beta version 2.1, the versioning system will change. Before the official release, you can connect the latest version of the API only via the link api-maps.yandex.ru/2.1-dev.
The API 2.1-beta API reference guide is published on the API website . Examples can be found in the sandbox . And also the beta version of Yandex.Map is already working on the new API.
Source: https://habr.com/ru/post/196288/
All Articles