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
