UI in an Enterprise application, or how we made a convenient system for creating maps
Usually we talk about how we make external products or their individual features - 2GIS itself, its graphics and typography, or Floors . At the same time, the topic of domestic products has never been raised. We correct this annoying oversight by the example of "Fiji" - a product for rendering an interactive map.
10 years ago, when 2GIS was still small, a map for it was created in its own system “DGPP”. It was a simple and understandable tool, as they say, " appropriate to the time of release ."
Every year the functions in it became more. It was necessary to create more objects and do it very quickly. After 10 years of “refinements”, DGPP became this:
In the bottom line:
- old technologies;
- artifacts whose sacred meaning has been lost for centuries;
- a pile of controls, which is difficult to navigate;
- problems with the introduction of new features.
There is no limit to perfection, but further it was impossible to “improve” and “modify” the product. It was necessary to create a new system.
At first we thought about ideology. It was necessary to understand what is good and what is evil, what principles will determine this or that decision?
Industrial map rendering is not an easy process and has its own subtleties:
Customers understood the complexity of the task, and no one talked about creating an “intuitive interface”. However, within each specific stage, the interface should become transparent and, as far as possible, prompt the user the path along which he should go.
Creating a map is an expensive process. It consists of hundreds of thousands of action cartographers. If a transaction becomes just a couple of clicks more, in the end, for a company, this change can cost a lot of money.
Therefore, the first principle was "do no harm." It would be a shame to make a beautiful product and understand that it takes longer to perform an elementary action than in a predecessor product.
In addition to the geometries of objects on the map, the product contains a large amount of related data.
For construction, for example, there is a purpose, address (street + house number), building material, number of entrances and floors, height, name and a dozen more two different attributes that need to be displayed.
This brings us to the second principle. Attributes and any data accompanying the map rendering should be visible, clearly distinguishable and not lost.
Surely, one of you has experienced the loss of data entered on different pages of the site. You write the exact address, first and last name, go to the second screen, press save ... lag ... the data is worn out, rabies, we start from the beginning.
In our case, lost data is not just a chagrin, but a waste of company funds. The system should take over the work of users. Using the default data, all kinds of automation and precalculations are what will help us with this.
DGPP is outdated, but it had a lot of good. Following processes, responsiveness, protection against random errors and much more. Users have formed habits, some of which speed up work. For us, this has become the third principle: if the old interface has something positive, convenient and useful, then this must be preserved. This will increase user loyalty and reduce their pain when switching to a new product.
External features regularly add new features that are tied to content. For internal products, this means constantly adding requirements and the need to maintain new data. This fact also needs to be considered when developing a system.
Historically, enterprise developers have focused more on creating new functionality than on sharpening interfaces. And when the question comes to implementation, priority is more often given to well-made logic than to the visual component. Therefore, nice looking, but simple design has a better chance of getting into production.
These principles allowed us to come to a consensus on controversial issues and determine the most appropriate ideas.
We agreed on the rules, it's time to start development. More precisely, with decomposition.
First of all, we examined the process of rendering a map. Fortunately for us, the technologists have described their business processes in detail and with love. If it didn’t work out with something, then the answer went to the predecessor system or directly to users.
They wrote down the processes and singled out common actions in them. For example, in terms of actions, drawing a house and a road is the same. Drawn an object => filled in the attributes => saved. Based on such a grouping, we identified functional blocks with the same goal.
After the task is decomposed, everything becomes simple. We prioritize and work out features individually.
Yes, creating a crossroads is a separate feature. More precisely, visualization of the process of creating and editing intersections.
Dive into the subject area a bit. We have a crossroads - this is the point at the intersection of road links.
Crossroads carry information about prohibited maneuvers. For example, you cannot turn from one street to another, or there is a barrier at the entrance to the courtyard.
First of all, we turned to the existing solution.
To enter attribute information, a window came off: The
user filled in the data and clicked “OK”. Positive point: the data in the window was pre-filled.
For example, in the field “level” the values of the level of links connected to the intersection were put down. The list of prohibited maneuvers was pulled up by the same principle. Most often, you could just click save. In addition, to ban each maneuver, one click was required, and for greater clarity, the maneuver was highlighted.
However, it was striking that the link ID as an identification mark of the maneuver was not very informative. The column “mode of transport” (meaning the mode of transport for which the ban applies) also did not inspire confidence.
There are two reasons. Firstly, several types of transport are not visible in the table. Secondly, to prohibit traffic on a particular type of transport, three clicks were required for each maneuver. Choosing a ban schedule also took more than three clicks.
After communicating with customers and users, the hypothesis of uninformative ID was confirmed. Users look more at the highlight of the maneuver on the map than at the ID. But the arrangement of prohibitions with check marks is considered convenient. We also found out that the schedule for maneuvers is rarely introduced and is not a key case.
After that, we had a number of ideas:
With these thoughts in mind, we moved on.
And then we had a question: did anyone try to solve a similar problem? And what came of it? We started to search.
Having studied more than 30 products, we identified 2 patterns that seemed to us applicable:
But we wanted to go a little further and combine these two approaches. Thus, we wanted to maintain the habit and give a more visual and technological tool.
The next step is to bring our ideas to the customer.
The easiest and fastest way is direct communication.
At the meetings, we drew sketches of ideas, described how they should work and immediately received feedback. It was important not only to understand whether our ideas are like or not, but to find out what exactly doesn’t suit and what practical cases are behind it.
We tried to get the maximum of applied information from the customer in order to get a unified view of the solution to the problem.
After several dialogs, the concept became like this:
After everyone agreed, we made the first version of the process visualization:
Controls for editing maneuvers through the map, in fact, are raster icons that are superimposed on the intersection and the links connected with it.
The distance between the icons is fixed and does not depend on scale.
In this case, the ability to change the scale of the map remains.
After the solution was shown to the customer, a few more nuances surfaced:
And we went to think further. The new option was this: The
new visualization took into account the complex cases of building intersections. As well as situations where on the map a lot of objects of the same type are nearby. In addition, we have illustrated intersection options at different scales.
As a result, we got a solution that allows you to:
Now that users are happy, it's time for the developers. It is worth mentioning right away that the developers participated in creating the solution at all stages.
Each concept was discussed with developers regarding its feasibility. The solution proposed in the end was user-friendly and technologically advanced, and the intersection editing functionality was critical for the first release of the product.
But its implementation took time and would delay the strength of the team. It was necessary to find a balance between functionality and convenience, so we decided to detail the task.
Maneuvers could be edited through the sidebar quickly. At the same time, it looked better than a similar solution in the old system. The ability to edit maneuvers from the map looks convenient, but users do not wait for it and, therefore, will not be upset if it is not in the first version.
In the harsh world of enterpise, graphical interfaces are more likely to answer the question “what?” Than to the questions “how?” And “why?”. Everywhere you can find systems that solve a functional problem, without paying due attention to the simplicity and convenience of its solution. But it’s just the convenience and following the problems and habits of users that allows you to create truly useful products.
Therefore, do not be afraid to invest time in the interface and search for convenient solutions. Create cool products that will really save users time, company money and developer nerves. Your work will not be in vain.
Background
10 years ago, when 2GIS was still small, a map for it was created in its own system “DGPP”. It was a simple and understandable tool, as they say, " appropriate to the time of release ."
Every year the functions in it became more. It was necessary to create more objects and do it very quickly. After 10 years of “refinements”, DGPP became this:
In the bottom line:
- old technologies;
- artifacts whose sacred meaning has been lost for centuries;
- a pile of controls, which is difficult to navigate;
- problems with the introduction of new features.
There is no limit to perfection, but further it was impossible to “improve” and “modify” the product. It was necessary to create a new system.
Training
Belief system
At first we thought about ideology. It was necessary to understand what is good and what is evil, what principles will determine this or that decision?
Industrial map rendering is not an easy process and has its own subtleties:
- A map is created in several stages.
First, it is drawn from satellite images, and then verified on the ground. For example, you can draw a building from the picture, but specify the number of storeys - only after reconciling on the ground. - Following the sequence when creating object classes.
Rivers, areas, houses, streets, etc. should be drawn in a certain sequence. For example, roads can cross houses, but they cannot cross rivers. - Atypical device of the city.
For example, from the presence in the city of complex hydrography, from the features of road junctions or the specific structures of buildings.
Customers understood the complexity of the task, and no one talked about creating an “intuitive interface”. However, within each specific stage, the interface should become transparent and, as far as possible, prompt the user the path along which he should go.
Noli nocere
Creating a map is an expensive process. It consists of hundreds of thousands of action cartographers. If a transaction becomes just a couple of clicks more, in the end, for a company, this change can cost a lot of money.
Therefore, the first principle was "do no harm." It would be a shame to make a beautiful product and understand that it takes longer to perform an elementary action than in a predecessor product.
Content comes first
In addition to the geometries of objects on the map, the product contains a large amount of related data.
For construction, for example, there is a purpose, address (street + house number), building material, number of entrances and floors, height, name and a dozen more two different attributes that need to be displayed.
This brings us to the second principle. Attributes and any data accompanying the map rendering should be visible, clearly distinguishable and not lost.
Time saving
Surely, one of you has experienced the loss of data entered on different pages of the site. You write the exact address, first and last name, go to the second screen, press save ... lag ... the data is worn out, rabies, we start from the beginning.
In our case, lost data is not just a chagrin, but a waste of company funds. The system should take over the work of users. Using the default data, all kinds of automation and precalculations are what will help us with this.
Inheritance
DGPP is outdated, but it had a lot of good. Following processes, responsiveness, protection against random errors and much more. Users have formed habits, some of which speed up work. For us, this has become the third principle: if the old interface has something positive, convenient and useful, then this must be preserved. This will increase user loyalty and reduce their pain when switching to a new product.
Extensibility
External features regularly add new features that are tied to content. For internal products, this means constantly adding requirements and the need to maintain new data. This fact also needs to be considered when developing a system.
Simplicity
Historically, enterprise developers have focused more on creating new functionality than on sharpening interfaces. And when the question comes to implementation, priority is more often given to well-made logic than to the visual component. Therefore, nice looking, but simple design has a better chance of getting into production.
These principles allowed us to come to a consensus on controversial issues and determine the most appropriate ideas.
Decomposition into blocks
We agreed on the rules, it's time to start development. More precisely, with decomposition.
First of all, we examined the process of rendering a map. Fortunately for us, the technologists have described their business processes in detail and with love. If it didn’t work out with something, then the answer went to the predecessor system or directly to users.
They wrote down the processes and singled out common actions in them. For example, in terms of actions, drawing a house and a road is the same. Drawn an object => filled in the attributes => saved. Based on such a grouping, we identified functional blocks with the same goal.
After the task is decomposed, everything becomes simple. We prioritize and work out features individually.
Crossroads
Yes, creating a crossroads is a separate feature. More precisely, visualization of the process of creating and editing intersections.
Dive into the subject area a bit. We have a crossroads - this is the point at the intersection of road links.
Crossroads carry information about prohibited maneuvers. For example, you cannot turn from one street to another, or there is a barrier at the entrance to the courtyard.
Task research (requirements collection)
First of all, we turned to the existing solution.
To enter attribute information, a window came off: The
user filled in the data and clicked “OK”. Positive point: the data in the window was pre-filled.
For example, in the field “level” the values of the level of links connected to the intersection were put down. The list of prohibited maneuvers was pulled up by the same principle. Most often, you could just click save. In addition, to ban each maneuver, one click was required, and for greater clarity, the maneuver was highlighted.
However, it was striking that the link ID as an identification mark of the maneuver was not very informative. The column “mode of transport” (meaning the mode of transport for which the ban applies) also did not inspire confidence.
There are two reasons. Firstly, several types of transport are not visible in the table. Secondly, to prohibit traffic on a particular type of transport, three clicks were required for each maneuver. Choosing a ban schedule also took more than three clicks.
After communicating with customers and users, the hypothesis of uninformative ID was confirmed. Users look more at the highlight of the maneuver on the map than at the ID. But the arrangement of prohibitions with check marks is considered convenient. We also found out that the schedule for maneuvers is rarely introduced and is not a key case.
After that, we had a number of ideas:
- The method of arranging maneuvers must be maintained, because users are used to it. However, it is worth making it more visual.
- It is impossible to make the arrangement of prohibitions on maneuvers automatic, because There are no signs by which this can be done 100% for sure. Therefore, it makes sense to make all maneuvers enabled by default, because This is the most common case.
- Link and attributes should be shown at the same time. So that the attributes do not overlap the map.
- Link ID as an identification mark of the maneuver does not work. We need something to replace it with. For example, the name of the street.
- Make it possible to edit the object where you create it. If you draw an intersection on the map, it’s logical to be able to arrange all the necessary prohibitions in the same place. There was an idea to edit forbidden maneuvers through the map.
- A ban on a particular type of transport is not a very frequent case, and the customer does not raise the issue of reducing the number of actions. However, if you use pictograms, you can make this element more compact and intuitive. This will add points to the decision as a whole and increase loyalty.
- The prohibition schedule - the case is not only rare, but also requires a lot of variability of actions. Accordingly, trying to make it faster is not only difficult, but also not advisable.
With these thoughts in mind, we moved on.
Research analogues
And then we had a question: did anyone try to solve a similar problem? And what came of it? We started to search.
Having studied more than 30 products, we identified 2 patterns that seemed to us applicable:
- Displays forbidden maneuvers in list form (JOSM). It seemed more visual than a table view, and replacing the ID with the street name was consistent with our idea.
- Visualization of prohibitions on the map.
But we wanted to go a little further and combine these two approaches. Thus, we wanted to maintain the habit and give a more visual and technological tool.
First ideas
The next step is to bring our ideas to the customer.
The easiest and fastest way is direct communication.
At the meetings, we drew sketches of ideas, described how they should work and immediately received feedback. It was important not only to understand whether our ideas are like or not, but to find out what exactly doesn’t suit and what practical cases are behind it.
We tried to get the maximum of applied information from the customer in order to get a unified view of the solution to the problem.
After several dialogs, the concept became like this:
- The attribute information of the intersection is shown in the panel on the right.
- Save the data prefill.
- We leave two ways to edit maneuvers (from the map and through the docpanel of attributes).
- Editing in the attributes is done in the form of a list of elements in two lines.
- Editing through the map is done with icons drawn on top of the vector map. At the same time, the ability to scale the map is preserved.
Process design
After everyone agreed, we made the first version of the process visualization:
Controls for editing maneuvers through the map, in fact, are raster icons that are superimposed on the intersection and the links connected with it.
The distance between the icons is fixed and does not depend on scale.
In this case, the ability to change the scale of the map remains.
After the solution was shown to the customer, a few more nuances surfaced:
- Due to the fact that two-line elements were used, the list of maneuvers was too cumbersome. And since the number of elements in it can be large, scrolling it is not always convenient.
- The link will not always have a street name. Even within the city, many roads do not have a name. For example, all kinds of intra-quarter driveways, park alleys, etc.
- It was not clear how the controls in the map would behave at a complex intersection. It was obvious right now that if the links intersect at an acute angle, then the icons overlap each other.
And we went to think further. The new option was this: The
new visualization took into account the complex cases of building intersections. As well as situations where on the map a lot of objects of the same type are nearby. In addition, we have illustrated intersection options at different scales.
As a result, we got a solution that allows you to:
- Quickly create intersections , as the fields are automatically filled for the most common case. In other words, we do not ask the user to enter data when this can be avoided.
- Create forbidden maneuvers in a more visual way. The arrangement of prohibitions through the list, since pictograms with the image of road signs look more understandable than checkboxes. In turn, the creation of maneuvers through the map facilitates the task when working with complex interchanges.
- Easy to adapt. Despite the fact that the appearance and position of the panel have changed, we have preserved its structure and the sequence of input data. In addition, we left the opportunity to place bans through the list. This allowed users to quickly get used to the new interface and saved time on training.
- Increase the amount of data collected. The block structure of the attribute panel allows you to easily expand it if you need to collect new data about intersections.
- Place bans for a particular type of transport in one click.
Design => Development => ???
Now that users are happy, it's time for the developers. It is worth mentioning right away that the developers participated in creating the solution at all stages.
Each concept was discussed with developers regarding its feasibility. The solution proposed in the end was user-friendly and technologically advanced, and the intersection editing functionality was critical for the first release of the product.
But its implementation took time and would delay the strength of the team. It was necessary to find a balance between functionality and convenience, so we decided to detail the task.
Maneuvers could be edited through the sidebar quickly. At the same time, it looked better than a similar solution in the old system. The ability to edit maneuvers from the map looks convenient, but users do not wait for it and, therefore, will not be upset if it is not in the first version.
And finally
In the harsh world of enterpise, graphical interfaces are more likely to answer the question “what?” Than to the questions “how?” And “why?”. Everywhere you can find systems that solve a functional problem, without paying due attention to the simplicity and convenience of its solution. But it’s just the convenience and following the problems and habits of users that allows you to create truly useful products.
Therefore, do not be afraid to invest time in the interface and search for convenient solutions. Create cool products that will really save users time, company money and developer nerves. Your work will not be in vain.