Комментарии 16
Если кратко — «не выпендривайтесь».
Максим Никитин, вам бы людей учить своему мастерству. Цифровой мир станет краше)
Ну тут да, уже все зависит от от задач и фантазии заказчика
Я считаю, что сначала проще по стандарту все запустить, а уж потом в дальнейшем выкладывать кругленькую сумму на кастомную анимацию
Ждем части второй, третьей и других )
Несколько раз, на моем опыте, убирали большинство анимационных «улучшений» после релиза.
Иногда вместе с командой программистов.
Несколько раз, на моем опыте, убирали большинство анимационных «улучшений» после релиза.
Иногда вместе с командой программистов.
Потому что на практике этот заебушек никуда не полетит.
А разве нельзя портировать элементы интерфейса с айфоновских приложений на андроидовские? Просто в шугл плэе полно лаунчеров, которые реализуют iOS интерфейс для Android пользователей…
О чем статья вообще?
На андройде все сложно делать, дрибл картинки не подходят для разработки?
– Ну как бы да, так о чем речь?
Думаю что дизайн хорошего приложения отличается от плохого тем, что хороший это сплав между функциональностью эстетикой и этикой, плохой же однобок и не предлагает ничего нового.
Чтобы создать хорошее приложение нужны знания как в области дизайна так и в области программирования. Сводить все к примитивным формам прикрываясь техническими ограничениями — такое себе.
На андройде все сложно делать, дрибл картинки не подходят для разработки?
– Ну как бы да, так о чем речь?
Думаю что дизайн хорошего приложения отличается от плохого тем, что хороший это сплав между функциональностью эстетикой и этикой, плохой же однобок и не предлагает ничего нового.
Чтобы создать хорошее приложение нужны знания как в области дизайна так и в области программирования. Сводить все к примитивным формам прикрываясь техническими ограничениями — такое себе.
Согласен, да и обычному дизайну по правилам можно за пол года обучится, а создать что то удобное и красивое, нужен художественный вкус
Вы правильно отметили — эстетика, этика и функционал. Подписываюсь под каждым словом. Это основа формирования как бренда так и продукта в его контексте. Статья — крик души и скромный вклад в понимание клиентами, что анимации с дрибла, зачастую, — не реальные примеры приложений. Кстати, из последнего, не совсем цитата, но близко к тексту: «Почему на дрибле столько красивых приложений, а в реальности ничего подобного нет?». Но когда даешь оценку времени на разработку анимашки (и не имею ввиду в Principle, AE или даже Framer :), то сразу приоритеты правильно расставляются.
Жду продолжения!
А еще популярный способ сделать так, чтобы дизайн выглядел на картинке лучше, чем он на самом деле может быть – убрать к чертовой матери все системные элементы, вроде статуса батареи, сети, уведомлений и кнопок навигации на Андроиде. Вроде как избавиться от мусора.
Так, конечно, выглядит более эффектно, но, поверьте, если мы заставим приложение скрывать системные элементы на экране пользователя, то матерный аналог вопроса «ну вот зачем?» будет сопутствовать каждому запуску вашей прекрасной аппликушки.
А пользователи SailfishOS смеются над такими пользователями, потому чтоу них в операционке по умолчанию приложение занимает весь экран, подглядеть состояние статусбара можно с помощью абсолютно ненапрягающего жеста «подглядывания» )
Чувствуется, что накипело у автора, но статья получилась очень полезная + юмор, вообще огонь! Жду 2-ю часть)
Как же это знакомо — на одном из прошлых проектов дизайнер настолько заморачивался с кастомным дизайном, что были такие свистоперделки, как кастомная тень (я, к примеру, никогда не видел красную тень, а там была)) всевозможные выезжалочки, транзишены, каждый UI-элемент выезжал по-своему… вся эта хрень настолько лишает апку быстродействия, что сильно раздражает. Причём, ни функционала, ни релиза толком не было, а свистелки подавай сразу же :)
Это правда. Обычно это происходит еще и тогда, когда у клиента нет четкой стратегии развития и монетизации продукта.
Кстати, мы стараемся прислушиваться к программистам и идем на упрощения в дизе, чтобы трудозатраты были разумными и адекватны прикручиваемой фичи. Ну например, радиус скругления 40 и смещение по X в 20 у свитчконтрола — даже для IOS перебор
Кстати, мы стараемся прислушиваться к программистам и идем на упрощения в дизе, чтобы трудозатраты были разумными и адекватны прикручиваемой фичи. Ну например, радиус скругления 40 и смещение по X в 20 у свитчконтрола — даже для IOS перебор
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сага о мобильном дизайне. Часть 1