The post has been translated automatically. Original language: Russian
How maps work in applications
The map in the application looks like a single picture, which you can use to move in any direction. In fact, it is assembled from many small square pictures.
Each such square is prepared in advance and separately for each scale. When you zoom in on the map, the app loads a new set of squares, more detailed.
Therefore, the map appears gradually. First, the general contours are visible, then the details are loaded. This is especially noticeable when the connection is slow.
A separate task is to turn an address into a point on the map. The person writes the street and the house number, and the map needs two coordinates. This is handled by a special service that matches text with known objects.
The reverse problem is also common. There are coordinates, you need to give the address. This is how location detection works based on the location of the phone.
The third task is the route. The roads on the map are described as a network of connected sections, each with a length, direction, and permissible speed. The route is the most profitable route through this network.
From this it is clear why the routes are sometimes surprising. If the data on the road section is incomplete, the calculation is based on what is known.
A useful conclusion for the product: a map is not a picture, but several different services. Any of them can be slow, and it's better to look at them separately.
Do you use ready-made maps in your products or do you use a list of addresses?
How does the card payment work in the app?
The user enters the card details, presses the button and sees the confirmation two seconds later. In these two seconds, the message passes through several participants.
The first participant is the service itself. An important rule is that the full details of the card are not saved in it. They are immediately transferred to the payment partner, and in return the service receives a short sign of the operation.
The second participant is the payment partner. He communicates with banks and takes on all the difficult work.
The third participant is the bank that issued the card. He is the one who decides whether the operation goes through or not, and he is the one who checks the account balance.
Another step is often added with confirmation from the bank when the user is asked to enter the code. This step is done by the bank, not the app.
Then there is an important detail that not everyone knows about. The write-off takes place in two steps. First, the amount is withheld, then it is confirmed. Time may pass between these actions, and the user sees an intermediate state in the statement.
Hence the practical conclusion. The application needs to be able to show the operation status honestly: withheld, confirmed, returned. One word paid for all cases causes a lot of calls to support.
And one last thing. The response from the payment partner may arrive later than the screen closes. Therefore, the application learns the final status by a separate message, and not just by responding to the button.
Do you show the user the difference between withholding and debiting the amount?
Why font and margins are more important than they seem
The interface is most often discussed in terms of the color and location of the buttons. At the same time, convenience is more strongly influenced by two things that are less talked about.: text and an empty space.
Let's start with the size of the text. Text that is too small is difficult to read, and the user simply skips it. This also applies to captions under fields where the most important thing is often written.
Next is the length of the string. A very long line is inconvenient: the eye loses the beginning of the next one. Therefore, in wide blocks, the text is limited in width, rather than stretched over the entire screen.
The distance between the lines also affects. Dense text looks like a single spot, and it's difficult to find the right place in it.
Separately, about the empty space. It is not a waste of space. It shows which elements are interconnected. The signature next to your field and far from someone else's is clearly legible.
A single scale of margins helps. For example, four, eight, sixteen, and twenty-four points. When the margins are taken from the scale, the interface looks assembled, even if it was made by different people.
And the number of text sizes. Three or four are almost always enough: headline, plain text, caption. Eight different sizes create a sense of randomness.
The check is simple. Open the screen on your phone and try to find the main action in two seconds. If you have to look closely, it's usually the texts and the margins, not the color.
Do you have a single scale of margins in your project, or is each screen configured separately?
Пользователь говорит, что стало медленно. Первое желание это начать смотреть код и искать неэффективное место. Обычно это самый долгий путь.Разумнее сначала посмотреть на числа. Полезны три вещи: сколько запросов приходит, сколько времени занимает ответ и как это время распределяется.Про распределение стоит сказать отдельно. Среднее время ответа почти бесполезно. Если девяносто запросов из ста выполняются за сто миллисекунд, а десять за пять секунд, среднее покажет приемлемое значение, а недовольны будут именно эти десять человек. Поэтому смотрят не среднее, а значения по верхним границам.Дальше время ответа делят по шагам. Сколько заняло обращение к хранилищу, сколько ожидание другого сервиса, сколько собственные вычисления. Обычно один шаг занимает большую часть времени, и работать нужно именно с ним.Самая частая причина медленной работы это не сложные вычисления, а много мелких обращений к данным. Классический случай: получили список из ста заказов, а потом на каждый заказ отдельно запросили клиента. Вместо одного обращения получается сто один.Вторая частая причина это лишние данные. Запрашивается вся запись целиком, хотя нужны два поля. На одной записи разницы нет, на сотне тысяч она заметна.Третья причина это ожидание по очереди. Три независимых обращения можно выполнить одновременно, а не одно за другим.Главное правило простое: сначала измерить, потом менять. Улучшение, сделанное по догадке, обычно тратит время команды и не меняет результат.А вы измеряете время ответа по шагам или видите только общее значение?
Share
