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
