Комментарии 12
- Подскажите, пожалуйста, подтвердилась ли гипотеза менеджера проекта?
- Как именно вы об этом узнали/планируете узнать?
- По каким измеримым параметрам оцениваете успех приложения?
- Как убеждаетесь, что нововведения не ухудшают эти параметры?
Наверное могу ответить сразу по всем пунктам. Время покажет)) А если серьезно, то есть некоторые объективные вещи, например с bottom navigation и swipe-up экранами действительно удобнее пользоваться одной рукой. Это же касается и UX. Но в реальности все может быть по другому. Что-то мы могли не предусмотреть. Будем собирать статистику, фидбэк от пользователей и улучшать))
— А как вы на RN сделали такой bottom bar со свайпом наверх? Это кастомный BottonTabBar из React-Navigation? Как это вообще работает?
— Что вы используете как компонент для BottomSheets? reanimated-bottom-sheet? react-native-modalize? Что-то свое?
— Были ли проблемы с клавиатурой?
А если кратко — респект и уважуха, хороший кейс.
— Что вы используете как компонент для BottomSheets? reanimated-bottom-sheet? react-native-modalize? Что-то свое?
— Были ли проблемы с клавиатурой?
А если кратко — респект и уважуха, хороший кейс.
Спасибо) Я дизайнер, а эти вопросы к фронту. Я задам их нашему front end разработчику и как только получу ответ, напишу вам.
Спасибо! Я просто тоже RN разработчик, дико интересно.
Вообще хорошо бы чтобы RN разработчики тоже опубликовали свой опыт, у вас классное приложение получилось.
Вообще хорошо бы чтобы RN разработчики тоже опубликовали свой опыт, у вас классное приложение получилось.
Ответы приехали))
1. Да, это кастомный BottonTabBar из пакета react-navigation
2. В начале действительно был использован reanimated-bottom-sheet, но в нашем случае он приводил к ошибке: при открытом свайп меню карта перехватывала touch events на себя, что делало закрытие меню крайне проблематичным. Баг специфичен для android. В результате мы вынуждены были прийти к самописному компоненту также основоннаму на связке reanimated+gesture-handler
3. Проблемы с клавиатурой (недостки в гибкости предлагаемого react-native API) были есть и будут похоже всегда. Мы решили её с помошью react-native-keyboard-manager (в основном) и стандартного KeyboardAvoidingView (где было необходимо)
1. Да, это кастомный BottonTabBar из пакета react-navigation
2. В начале действительно был использован reanimated-bottom-sheet, но в нашем случае он приводил к ошибке: при открытом свайп меню карта перехватывала touch events на себя, что делало закрытие меню крайне проблематичным. Баг специфичен для android. В результате мы вынуждены были прийти к самописному компоненту также основоннаму на связке reanimated+gesture-handler
3. Проблемы с клавиатурой (недостки в гибкости предлагаемого react-native API) были есть и будут похоже всегда. Мы решили её с помошью react-native-keyboard-manager (в основном) и стандартного KeyboardAvoidingView (где было необходимо)
Интересный кейс, интересно было посмотреть на редизайн изнутри, спасибо!
Спасибо за кейс!
А скажите, сколько времени ушло на первый релиз приложения, и потом на редизайн?
И, я так понимаю, приложение с самого начала на react native писали, верно?
А скажите, сколько времени ушло на первый релиз приложения, и потом на редизайн?
И, я так понимаю, приложение с самого начала на react native писали, верно?
По поводу количества времени на первый релиз уточню. Я пришел в команду в качестве продуктового дизайнера, когда приложение было уже примерно год в сторе. Первые, тестовые экраны редизайна я начал делать прямо перед запланированным двухмесячным рефакторингом. Перерисовка экранов не заняла много времени, т.к. основные сценарии уже были. Наверное дизайн занял менее месяца. Но после рефакторинга, до сих пор всплывают проблемы, требующие решения. Это касается всего и фронта, и бэка, и дизайна.
Да, сразу на RN писали.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Редизайн приложения — взгляд изнутри