Очевидные ошибки при разработке мобильных приложений, ч.1
Существуют ошибки при разработке мобильных приложений, которые встречаются достаточно часто у разных разработчиков. В этой серии постов, я покажу тебе те, которые я видел чаще всего.
Итак, начнем.
Статус бар (это там, где мы видим время, значки вай-фая, батарейки и пр.) - очень важен, потому что она предоставляет пользователю основную информацию, не заставляя сворачивать приложение. Как ни странно, если пользователь начинает выходить из приложения, потом обратно разворачивать его из бекграунда, то это (А!) может породить ошибки состояния и (Б!) вцелом заставляет пользователя покидать среду обитания, которую мы ему создали, а следовательно возрастает вероятность пользователей потерять. В некоторых специфических случаях, например в игровых приложениях, которые предполагают игру в альбомной ориентации, может быть хорошей идеей разместить время, состояние сети и заряд батареи в другом месте экрана, чтобы это не стало причиной для выхода из приложения. В остальных случаях убедись, что информация на строке состояния читаема, независимо от цвета фона под статус баром.
#common_issues
Существуют ошибки при разработке мобильных приложений, которые встречаются достаточно часто у разных разработчиков. В этой серии постов, я покажу тебе те, которые я видел чаще всего.
Итак, начнем.
Статус бар (это там, где мы видим время, значки вай-фая, батарейки и пр.) - очень важен, потому что она предоставляет пользователю основную информацию, не заставляя сворачивать приложение. Как ни странно, если пользователь начинает выходить из приложения, потом обратно разворачивать его из бекграунда, то это (А!) может породить ошибки состояния и (Б!) вцелом заставляет пользователя покидать среду обитания, которую мы ему создали, а следовательно возрастает вероятность пользователей потерять. В некоторых специфических случаях, например в игровых приложениях, которые предполагают игру в альбомной ориентации, может быть хорошей идеей разместить время, состояние сети и заряд батареи в другом месте экрана, чтобы это не стало причиной для выхода из приложения. В остальных случаях убедись, что информация на строке состояния читаема, независимо от цвета фона под статус баром.
#common_issues
Очевидные ошибки при разработке мобильных приложений, ч.2
Правильное размещение Floating Action Button в приложениях. Это интуитивный и легкодоступный элемент, но его логика может серьезно пострадать, если не учитывать особенности экранных отступов, особенно системы навигации. Давай разберем основные моменты, которые необходимо учитывать:
1. Панель навигации: Кнопка может быть частично закрыта навигационной панелью, что уменьшает ее кликабельную область. Это самый распространенный тип ошибки при создании Floating Button
2. Программные кнопки: Влияют на большинство Android-устройств, так как программную навигацию можно включить в настройках устройства. Очень важно учитывать этот случай, так как для некоторых версий Android это единственный тип навигации.
3. Жесты: В целом, самый непроблемный вариант, так как он не добавляет отступы на экране.
4. Кнопка может слишком близко располагаться к другим кнопкам или элементам навигации, что плохо скажется на интерфейсе и UX. Т.е. пользователь может промахиваться и тапать по другим элементам вне FAB.
#common_issues
Правильное размещение Floating Action Button в приложениях. Это интуитивный и легкодоступный элемент, но его логика может серьезно пострадать, если не учитывать особенности экранных отступов, особенно системы навигации. Давай разберем основные моменты, которые необходимо учитывать:
1. Панель навигации: Кнопка может быть частично закрыта навигационной панелью, что уменьшает ее кликабельную область. Это самый распространенный тип ошибки при создании Floating Button
2. Программные кнопки: Влияют на большинство Android-устройств, так как программную навигацию можно включить в настройках устройства. Очень важно учитывать этот случай, так как для некоторых версий Android это единственный тип навигации.
3. Жесты: В целом, самый непроблемный вариант, так как он не добавляет отступы на экране.
4. Кнопка может слишком близко располагаться к другим кнопкам или элементам навигации, что плохо скажется на интерфейсе и UX. Т.е. пользователь может промахиваться и тапать по другим элементам вне FAB.
#common_issues
Очевидные ошибки при разработке мобильных приложений, ч.3
Иногда нам кажется, что содержимое экрана или виджета фиксировано и не требует прокрутки. При этом сам виджет может занимать половину (или даже больше) экрана. К сожалению, разработчики не всегда вспоминают про пользователей с небольшими устройствами (а ведь есть люди с iPhone SE, а Google планирует выпускать компактную версию Pixel). А еще реже разработчики забывают про появление клавиатуры для ввода текста. Представьте, что пользователь пытается ввести логин и пароль, а клавиатура перекрывает важные элементы интерфейса. Хотя что тут представлять, очень часто ты это можешь наблюдать в куче приложений.
Чтобы избежать таких проблем, стоит предусмотреть возможность прокрутки всех экранов. Даже если прокрутка на первый взгляд не нужна, её наличие обеспечит гибкость интерфейса. Если ты переживаешь, что пользователь начнет постоянно свайпать по экрану, то сразу заложи, функционал, при котором элементы плавно вернутся на свои места.
#common_issues
Иногда нам кажется, что содержимое экрана или виджета фиксировано и не требует прокрутки. При этом сам виджет может занимать половину (или даже больше) экрана. К сожалению, разработчики не всегда вспоминают про пользователей с небольшими устройствами (а ведь есть люди с iPhone SE, а Google планирует выпускать компактную версию Pixel). А еще реже разработчики забывают про появление клавиатуры для ввода текста. Представьте, что пользователь пытается ввести логин и пароль, а клавиатура перекрывает важные элементы интерфейса. Хотя что тут представлять, очень часто ты это можешь наблюдать в куче приложений.
Чтобы избежать таких проблем, стоит предусмотреть возможность прокрутки всех экранов. Даже если прокрутка на первый взгляд не нужна, её наличие обеспечит гибкость интерфейса. Если ты переживаешь, что пользователь начнет постоянно свайпать по экрану, то сразу заложи, функционал, при котором элементы плавно вернутся на свои места.
#common_issues
Очевидные ошибки при разработке мобильных приложений, ч.4
При разработке приложений обычно удобнее использовать симулятор/эмулятор устройства для тестирования, а не реальное устройство. Зачастую, разработчик при этом использует физическую клавиатуру (да, которая лежит на столе) для ввода текста в приложении и скрывает программную. Это, конечно, ускоряет процесс разработки, но в дальнейшем появляются "прогалы", где он не проверил - а как ведет себя приложение при открытой клавиатуре.
На небольших устройствах клавиатура может вообще занимать значительную часть экрана, из-за чего все может "поплыть" или быть нечитабельным.
Когда ты тестируешь своё приложение на симуляторе, попробуй воспроизвести реальные сценарии использования, чтобы понять, как оно будет работать на различных устройствах. Это включает проверку работы с разными размерами экранов и разрешениями, а также с различными версиями операционных систем. Такой подход поможет выявить потенциальные проблемы заранее и сделать приложение более стабильным.
Ну и, конечно, протестируй на реальных устройствах, особенно на тех, которые наиболее популярны среди твоей целевой аудитории (если, конечно, есть такая возможность). Это поможет выявить такие проблемы, которые могут не быть очевидными при использовании симуляторов и позволит увидеть, как приложение работает в реальных условиях.
#common_issues
При разработке приложений обычно удобнее использовать симулятор/эмулятор устройства для тестирования, а не реальное устройство. Зачастую, разработчик при этом использует физическую клавиатуру (да, которая лежит на столе) для ввода текста в приложении и скрывает программную. Это, конечно, ускоряет процесс разработки, но в дальнейшем появляются "прогалы", где он не проверил - а как ведет себя приложение при открытой клавиатуре.
На небольших устройствах клавиатура может вообще занимать значительную часть экрана, из-за чего все может "поплыть" или быть нечитабельным.
Когда ты тестируешь своё приложение на симуляторе, попробуй воспроизвести реальные сценарии использования, чтобы понять, как оно будет работать на различных устройствах. Это включает проверку работы с разными размерами экранов и разрешениями, а также с различными версиями операционных систем. Такой подход поможет выявить потенциальные проблемы заранее и сделать приложение более стабильным.
Ну и, конечно, протестируй на реальных устройствах, особенно на тех, которые наиболее популярны среди твоей целевой аудитории (если, конечно, есть такая возможность). Это поможет выявить такие проблемы, которые могут не быть очевидными при использовании симуляторов и позволит увидеть, как приложение работает в реальных условиях.
#common_issues
Очевидные ошибки при разработке мобильных приложений, ч.5
Когда мы говорим о поддержке нетипичных экранов - очень маленьких или складывающихся (типа Samsung Fold / Flip), то мы это воспринимаем это, как достаточно редкие случаи. Но, на самом деле, это далеко не экзотика. Сейчас размеры экранов варьируются от 4 дюймов до (чуть ли) не бесконечности.
Процент пользователей, которых мы исключаем, то есть фактически тех, у кого качество приложения ухудшается — это то, на что стоит обратить внимание. Даже снижение доступности для 1% пользователей может значительно повлиять на конверсию.
Правильно реализованные приложения на Flutter обеспечивают адаптивность. Решение упомянутых проблем сделает приложение как минимум пригодным для использования на маленьких экранах, что уже может быть достаточно. Однако поддержка очень маленьких экранов часто требует дополнительных мер, помимо корректного поведения и масштабируемости. Иногда это включает в себя настройку UX или скрытие ненужных элементов, аналогично тому, как мы оптимизируем сайты для веб-платформ.
Не забывай, что создание удобного приложения для всех пользователей, независимо от их устройства, значительно повысит их удовлетворенность и, как следствие, улучшит оценку приложения. Ну и не забывай, что люди, которым в приложении нравится всё - не оставляют оценку, но вот недовольные пользователи сразу бегут об этом всем сообщать.
❗️Это была финальная часть постов про очевидные ошибки, поэтому время подвести итоги.
Решение всех описанных ранее проблем обычно включает реализацию продуманной логики на экранах, коррекцию отступов и изменение заполнения виджетами экрана по мере необходимости. Кроме этого, необходимо проводить тщательное тестирование на различных устройствах с разными размерами экранов, операционными системами и версиями, а также настройками устройств (например, системной навигацией). Это занимает много времени и может создаеть множество дефектов в JIRA. Но лучше они будут в таск-трекере, чем у пользователя.
В идеале, тебе (или тестированию) нужно создать чек-лист проверки корректной работы всех элементов приложения. Это не ускорит процесс на старте, но позволит сэкономить время в будущем.
А пока можешь почитать о Голден-тестах на Flutter: [тык]
#common_issues
Когда мы говорим о поддержке нетипичных экранов - очень маленьких или складывающихся (типа Samsung Fold / Flip), то мы это воспринимаем это, как достаточно редкие случаи. Но, на самом деле, это далеко не экзотика. Сейчас размеры экранов варьируются от 4 дюймов до (чуть ли) не бесконечности.
Процент пользователей, которых мы исключаем, то есть фактически тех, у кого качество приложения ухудшается — это то, на что стоит обратить внимание. Даже снижение доступности для 1% пользователей может значительно повлиять на конверсию.
Правильно реализованные приложения на Flutter обеспечивают адаптивность. Решение упомянутых проблем сделает приложение как минимум пригодным для использования на маленьких экранах, что уже может быть достаточно. Однако поддержка очень маленьких экранов часто требует дополнительных мер, помимо корректного поведения и масштабируемости. Иногда это включает в себя настройку UX или скрытие ненужных элементов, аналогично тому, как мы оптимизируем сайты для веб-платформ.
Не забывай, что создание удобного приложения для всех пользователей, независимо от их устройства, значительно повысит их удовлетворенность и, как следствие, улучшит оценку приложения. Ну и не забывай, что люди, которым в приложении нравится всё - не оставляют оценку, но вот недовольные пользователи сразу бегут об этом всем сообщать.
❗️Это была финальная часть постов про очевидные ошибки, поэтому время подвести итоги.
Решение всех описанных ранее проблем обычно включает реализацию продуманной логики на экранах, коррекцию отступов и изменение заполнения виджетами экрана по мере необходимости. Кроме этого, необходимо проводить тщательное тестирование на различных устройствах с разными размерами экранов, операционными системами и версиями, а также настройками устройств (например, системной навигацией). Это занимает много времени и может создаеть множество дефектов в JIRA. Но лучше они будут в таск-трекере, чем у пользователя.
В идеале, тебе (или тестированию) нужно создать чек-лист проверки корректной работы всех элементов приложения. Это не ускорит процесс на старте, но позволит сэкономить время в будущем.
А пока можешь почитать о Голден-тестах на Flutter: [тык]
#common_issues