Comments 12
Да, примеры действительно не помешали бы.
А еще интересен список тех самых «единичных» приложений, которые вы оценили.
А еще интересен список тех самых «единичных» приложений, которые вы оценили.
+4
Об этом как раз напишу в продолжении, с картинками и подробным разбором что хорошо, а что не очень
+2
Максим, если не секрет, а вы делали дизайн каких-нибудь мобильных приложений? Интересно было бы посмотреть.
+2
При чтении возникло стойкое ощущение, что перечитываю рекомендации MS к Метро-интерфейсам. Воспринимается как рерайтинг их рекомендаций.
+1
Интересная статья очень сильно смахивает на один общедоступный guidline на английском, ну да бог с ним.
В качестве примера случай когда пользователь редактирует текст или рисует, скрывать панель (бар) с дополнительными кнопками не рекомендуется.
Уверен найдутся случаи, когда кнопка лучше свайпа, когда панель управления удобнее всего зафиксировать
В качестве примера случай когда пользователь редактирует текст или рисует, скрывать панель (бар) с дополнительными кнопками не рекомендуется.
0
Автор пересказал некоторые аспекты изложенные в фундаментальном для iOS разработчиков документе Human Interface Guidline
Делать инерционную прокрутку по горизонтали для веб-сайтов — моветон. Скрывающиеся элементы управления хороши, когда их сокрытие и появление — очевидны для пользователя. Тоже самое относится к жестам — пихать жесты всюду — признак дурного тона, когда они не очевидны или далеко отступают от сложившегося стереотипного формата.
Типичный пример: некоторым заказчикам очень нравится свап вправо / влево в таблицах, и они ТРЕБУЮТ чтоб на нем была завязана определенная функциональность, хотя, всем пользователям iOS хорошо известно, что именно с помощью этого жеста удаляются элементы таблицы.
Делать инерционную прокрутку по горизонтали для веб-сайтов — моветон. Скрывающиеся элементы управления хороши, когда их сокрытие и появление — очевидны для пользователя. Тоже самое относится к жестам — пихать жесты всюду — признак дурного тона, когда они не очевидны или далеко отступают от сложившегося стереотипного формата.
Типичный пример: некоторым заказчикам очень нравится свап вправо / влево в таблицах, и они ТРЕБУЮТ чтоб на нем была завязана определенная функциональность, хотя, всем пользователям iOS хорошо известно, что именно с помощью этого жеста удаляются элементы таблицы.
+3
Вроде бы в iOS HIG настоятельно рекоммендуют не использовать собственные жесты. Если каждый разработчик будет добавлять свои жесты, то пользователь начнёт путаться в том, какой жест что и где делает. Если возможно, то стандартные жесты поддерживать надо, конечно, но не более.
Естественно, возможны исключения, но и к ним нужно подходить с особой тщательностью — вводить новый жест стоит только тогда, когда есть полная уверенность, что жест «интуитивен». А картинку с описанием жестов треть пользователей и смотреть не будет (они приложение скачали чтобы фоточку обработать, а не чтобы жесты заучивать), а ещё одна треть забудет через пять минут о её существовании.
Ну и про панельки согласен с вами. Более того, если не ошибаюсь, в гайдлайнах iOS и Android опять же рекомендуется не скрывать то, что может понадобиться пользователю вот прямо сейчас, а у скрытых панелек оставлять торчащий ярлычок для раскрытия.
Проблема swipe в том, что это «неточный» жест — им пользуются не точечно обычно, а на какой-то большой области. А потому у него область применения принципиально другая, нежели у tap. Для точных действий, кстати, есть slide(?) (разблокировка экрана как пример), но его, ИМХО, пользователю делать сложнее, чем и swipe, и tap.
А статья всё равно хорошая. Как минимум она заставляет задуматься над некоторыми «канонами», а не слепо следовать рекомендациям из гайдлайнов.
Естественно, возможны исключения, но и к ним нужно подходить с особой тщательностью — вводить новый жест стоит только тогда, когда есть полная уверенность, что жест «интуитивен». А картинку с описанием жестов треть пользователей и смотреть не будет (они приложение скачали чтобы фоточку обработать, а не чтобы жесты заучивать), а ещё одна треть забудет через пять минут о её существовании.
Ну и про панельки согласен с вами. Более того, если не ошибаюсь, в гайдлайнах iOS и Android опять же рекомендуется не скрывать то, что может понадобиться пользователю вот прямо сейчас, а у скрытых панелек оставлять торчащий ярлычок для раскрытия.
Проблема swipe в том, что это «неточный» жест — им пользуются не точечно обычно, а на какой-то большой области. А потому у него область применения принципиально другая, нежели у tap. Для точных действий, кстати, есть slide(?) (разблокировка экрана как пример), но его, ИМХО, пользователю делать сложнее, чем и swipe, и tap.
А статья всё равно хорошая. Как минимум она заставляет задуматься над некоторыми «канонами», а не слепо следовать рекомендациям из гайдлайнов.
0
Честно, я не понял, зачем была написана эта статья. Если Вы сами не разрабатывали пальцеориентированные программы, то понятна наивность в изложении. Любой минимально грамотный разработчик под подобные платформы уже знает то что написано и ему это знать не нужно. Тот же, кто пишет программы под iOS/Android/WP и делает их заведомо неудобными, просто не хочет этого делать. Для кого Вы изложили эти правила? Свои наблюдения нужно не просто излагать как они есть, а пропустить через фильтр полезности. Если Вы сами ими не пользуетесь и не имеете опыта в данной области, то почему Вы решили что именно Ваши советы полезнее того, что уже создано профессионалами и используется в данной отрасли? И соответственно, по этим руководствам написаны лучшие экземпляры программ.
+1
Автор, какие жесты с вашей точки зрения будут наиболее удобными и полезными? Хорошо бы уточнить их список.
0
Простыня текста…
Ну можно хоть каким-то диаграммами, картинками разбавить?
Это к вопросу об интерфейсах ;)
Ну можно хоть каким-то диаграммами, картинками разбавить?
Это к вопросу об интерфейсах ;)
0
Only those users with full accounts are able to leave comments. Log in, please.
Управление пальцами: в поисках идеального интерфейса