Неправильно ли использовать курсор для интерактивных элементов, таких как кнопки?
Я всегда считал, что курсор - идеальный визуальный индикатор для "вы можете нажать здесь" для пользователя. Мы привыкли видеть это в этом контексте ежедневно из-за его использования на гиперссылках и, следовательно, на всех веб-кнопках.
![alt text]()
Однако большинство настольных приложений, похоже, удерживают указатель стрелки указателя поворота для кнопок.
![]()
Я действительно чувствую себя лучше, когда кнопки, и другие элементы, доступные кликабе, такие как флажки и переключатели, используют курсор руки. Мне почему-то кажется, что мне нравится видеть этот курсор, когда я наводил на него элементы с возможностью клика, возможно, потому, что он соответствует тому, как это делают веб-страницы и даже многие игры.
Но, как разработчики, мы должны думать о пользователе children, а иногда делать что-то не так, как нам нравится, но так, как им нравится. Проблема в том, что я чувствую себя настолько нечетко о ручном курсоре на кнопках, что я слеплю о возможности его неуместности. Многие дизайнерские ошибки вызваны такими личными решениями.
![enter image description here]()
Что вы думаете об этом?
Изменить: Недавно я обратил внимание на использование ручного курсора в Photoshop (CS3 на XP), но, вероятно, только потому, что я использовал его более широко. Снимок экрана:
![enter image description here]()
Заметьте, что многие из мест, где была использована рука, явно доступны для просмотра.
EDIT2: Также обратите внимание, что они даже использовали пользовательский курсор, который, честно говоря, я никогда не делал, особенно для чего-то тривиального, как ручного курсора, который так вездесущ. И это даже не красиво.
Ответы
Ответ 1
Причина, по которой курсор меняет форму, когда гиперссылка, вероятно, имеет отношение к следующему:
- гиперссылки начинались в блоках текста, и поэтому не было видно, что вы можете щелкнуть по ним, чтобы открыть другую страницу.
- изменение стиля отображения для ссылок в самом себе, вероятно, было недостаточным для того, чтобы сообщить о "кликабельности" ссылки. Возможно, также потому, что изменения в стиле отображения не совсем стандартизированы, а курсор рукописного ввода.
- на веб-страницах, которые обычно были "кликабельными", я думаю, хотя я не могу вспомнить, вызвали ли они изменение формы. В настоящее время "кнопки" часто "подделываются" с использованием css, и вам нужно еще один способ сообщить пользователю, что они могут щелкнуть по нему = > для этого стал по умолчанию курсором handshape.
Все вышеперечисленное, однако, предназначено для передачи "clickablity" в пределах содержимого веб-страницы. Кнопки, кнопки на панелях инструментов, пунктах меню и т.д. Всегда были доступны без изменения формы курсора. И вы не видите, чтобы браузеры меняли форму курсора, когда вы нависаете над элементом меню или кнопкой панели инструментов.
В настольном приложении вы, вероятно, не поменяли бы курсор над каждым элементом в дереве, даже если он вызывает различную информацию в панели в сторону дерева? Или для каждого элемента, который вы можете выбрать в списке? Или для радиоблоков или флажков на форме? Итак, зачем это делать для кнопок формы, которые в настольном приложении всегда были легко идентифицированы и являются кликабельными по своей природе.
Я бы не изменил форму курсора для чего-либо в настольном приложении, которое (как всегда понималось) "clickable по своей природе". Я бы использовал только "веб-подобные" фигуры курсора при отображении информации в стиле "веб-как". Например, интерактивные части текста в сетке, в которых текст обычно не доступен для кликов. В противном случае я бы придерживался стандартных форм курсора. Это также помогает удержать "шум" в пользовательском интерфейсе.
обновление в ответ на комментарий (и)
@Camilo: Я получаю различие "команда" и "выбор". Я бы даже добавил "навигацию" к этому миксу. Тем не менее, я все еще не вижу необходимости менять формы курсора на команде ui-element.
Различие между навигацией и командой может несколько размываться, если вы думаете о них как просто как ответы на действия пользователя. Для меня есть четкое различие между ними. Навигация - все действия для открытия форм, выбора элементов и т.д. В общем, просто рыться вокруг... Команды - это все действия, которые заставляют данные изменять, вызывать уведомления (почту, сообщения любого рода) или где инициированное действие может занимать больше секунды или два (установление соединения, фильтрация большого набора данных).
Неправильно: если вы отправите форму в Интернете с помощью "POST" (или "DELETE" ), это, вероятно, будет командой, тогда как все остальное будет навигацией.
Во всяком случае, одна вещь, которую я никогда не делал бы, - это ui-элемент, который, естественно, больше ориентирован на навигацию и выбор (например, на дерево), выполняет команду. Поэтому, когда щелчок на элементе treeview, вероятно, изменит содержимое какой-либо другой части пользовательского интерфейса, в моих приложениях он никогда, например, не инициирует платеж...
Как таковое, дерево возможных серверов для подключения к нему, по-прежнему является элементом выбора. Я надеюсь, что фактическое соединение не будет сделано одним кликом, но только при двойном щелчке элемента или после того, как элемент будет выбран при нажатии кнопки "connect". И поэтому в этом конкретном случае я все равно не буду использовать курсор с мышкой на дереве.
Ответ 2
Лично я нашел в своих исследованиях, что это обычно воспринимается как один из тех, "мы всегда делали это так, так что это ожидаемый и лучший способ сделать это".
Ручной курсор сделал одно из самых ранних проявлений в стеках гиперкарты. Которые были ориентированы на менее опытных пользователей. Таким образом, как и многие вещи, его подхватили и унесли вместе с нами.
Однако, из-за его непоследовательного использования, я не думаю, что действительно существует "лучший" выбор между стрелкой и рукой... люди привыкли к одному и/или к обоим, поэтому любое последовательное, продуманное использование обоих представляется в целом эффективным.
Для меня, хотя я придерживаюсь следующих рекомендаций:
Стрелки для элементов, которые явно доступны для кликов, например, такие, как кнопки, переключатели, выпадающие меню и т.д. Рука полезна, когда вам нужно дать что-то, что может или не может появиться на кнопке, как небольшое дополнительное внимание. Это действительно отменяет призыв к действию "click-me!", "Click-me!".
Кроме того, в Интернете я заметил, что рука имеет тенденцию указывать элементы, которые при нажатии на нее будут отображаться БОЛЕЕ релевантный контент относительно того, на что вы только что нажали, в то время как стрелка кажется более управляемой командой, то есть "do это сейчас".
Но, как я уже сказал, до тех пор, пока это согласовано, пользователи быстро настроятся на использование вами какого-либо курсора, потому что они уже давно подвергаются воздействию обоих. Единственная реальная проблема возникает, когда вы несовместимы в обработке двух типов курсоров.
ИМХО - Нет ничего, что по сути было бы "интуитивным". Интуитивный - это еще один способ сказать "более знакомый" или "менее знакомый".
Ответ 3
Рука AFAIK была сброшена для толстых клиентских приложений, и вместо этого у вас есть кнопки и другие пользовательские элементы, которые испускают подсказки или имеют эффект "зависания".
Оставайтесь с ручным курсором ТОЛЬКО, если вы хотите имитировать внешний вид веб-приложения и чувствовать себя.
Ответ 4
интересный момент. Позвольте мне попытаться сделать это простым.
Стрелки - являются понятными для интерфейсов Desktop App +, которые очень интуитивно понятны
Рука - должна присутствовать в HYPER TEXT, для обычного пользователя важно знать, какой текст доступен клику.
Ответ 5
Я также думаю, что мы должны помнить, что рука обычно указывает на ссылку на другое место.
Я не думаю, что есть ясный ответ, но для меня, если платформа, на которой я кодирую (Windows), я просто буду следовать примерам базовой ОС, чтобы она была последовательной, что означает отсутствие значков рук для кнопок в Windows.
Как пользователь, мне кажется неудобно видеть значок руки в графическом интерфейсе Windows (если только я не перейду к ссылке, которая приведет меня на сайт)
Ответ 6
Я пришел сюда, думая, что этот вопрос будет иметь четкий ответ, но, глядя на эти ответы, а также на главные сайты показывает очень размытые различия. Поскольку линия между веб-и настольным клиентом размывается, я наблюдаю подобное размывание поведения.
Раньше... настольные клиенты почти всегда использовали один курсор и наводили кнопку для изменения видимого состояния, указывающего область кликабельности. На веб-страницах было изменение курсора на ссылках, и не было согласованного поведения, когда действие было обработано javascript.
Переход на некоторые из наиболее часто используемых веб-сайтов и приложений вокруг, я нахожу... Как пользователь, мне все равно, как я думал. Клиенты Deskstop в основном просто меняют кнопку, и если курсор меняется, я не замечаю. Веб-клиенты имеют тенденцию менять курсор И часто применяют визуальное состояние наведения курсора, и редко замечают, когда они этого не делают.
Пока кто-то не делает убедительного аргумента в противном случае, я пойду с самым простым правилом для нашего дизайна: всегда меняя курсор на действия и применяя кнопки для регулярного использования кнопок.
Ответ 7
Курсор "указатель" должен использоваться для гиперссылок или любого объекта, который функционирует как гиперссылка.
в противном случае курсор по умолчанию должен использоваться для всех других элементов, которые можно щелкнуть, таких как кнопки, переключатели, переключатели, выпадающие меню и т.д., поскольку по своей природе "должен" выглядеть как элемент, который можно щелкнуть.
Посмотрите определение гиперссылки для получения дополнительной информации.
Пример: Google Диск