Здравствуйте, squiz, Вы писали:

S>Ну уж нет! Скажите, насколько интуитивно то, что для открытия двери нужно повернуть/потянуть за ручку? Представьте себе что вы этого не знаете, как и того, что перед вами дверь которую можно открывать и что это дверь. Если вы знаете что такое стена, эта самая дверь для вас будет ничем иным как такой-же стеной, только другого цвета/материала/... и с выпуклостью (ручкой). Ну и как? Интуитивно? Думаю, с большей вероятностью вы будете пытаться давить на этот кусок стены (дверь)...

S>А в общем, согласен с пред. постами: это не сложно, точно так же как и обращение с мышью (сперва некоторые пользователи не могут уловить как движение руки соотносится с движением курсора на экране и постоянно смотрят на мышь). Интуитивно ли это? Ну, не более чем дабл клик или клик, если вы не знакомы с интерфейсом.
Я смотрю, ничто не останавливает любителей спорить с очевидным. Ок, продолжим. Ваша фраза "ну, не более чем" либо является фигурой речи, либо выдает ваше полное незнакомство с предметом.
Итак, рассмотрим сначала техническую сложность.
1. Клик: нужно
— привести курсор в активную зону (трудность обратно пропорционально квадрату поперечного размера, т.е в кнопку 8*8 попасть в 4 раза труднее, чем в 16*16)
— удерживая его на месте, нажать и отпустить кнопку мыши. К счастью, в винде принято

2. Дабл клик: все то же самое, плюс
— нужно выполнить второй клик, причем в пределах отведенного времени (около 500 мс) и в пределах 5px от точки первого клика.
В общем, ничего особенно сложного, хотя и требует определенной координации движений. Важно правильно выбрать усилие нажатия на кнопку и его направление, чтобы не сдвинуть мышь. Кстати, разочарую тех, кто думает, что это фигня — 90% из вас все-таки сдвигают мышь при дабл-клике; именно поэтому есть софтное загрубление детектирования позиции второго клика.

3. Драг-н-дроп. Это такой суперусложненный клик, который требует нажатия в одном месте, а отпускания в другом.

При этом это самый долгий из маневров, причем с постоянным напряжением руки. Психологически он тоже тяжел, т.к. досрочное отпускание приведет в лучшем случае к тому, что все придется начинать сначала, причем ошибка при даблклике позволяет тут же повторить его (мышь уже находится в нужном месте), а ошибка при драг-н-дропе потребует заново прицеливаться, а в худшем случае — к тому, что придется мучительно выяснять, что за действие только что произошло, и еще мучительнее придумывать обратное действие. Далеко не все драг-н-дроп системы поддерживают драг-н-дроп. Вот представьте, что надо перетащить кнопку офисного тулбара в другой тулбар — внизу. Мы делаем альт-драг и тащим. Если нам не повезло уронить ее над документом, а не над тулбаром — все, труба. Построение списка действий для исправления этой ошибки оставляю в качестве домашнего задания (кстати, офис заботливо сохранит новый вид тулбара в ваших сеттингах.)

Самое сложное упражнение, которое я встречал — это
— начать драг в окне, допустим, эксплорера
— переключиться в другое приложение
— навестись на дерево папок в нем, и при помощи слалома распахнуть и проскроллить нужную папку на глубоком уровне вложенности

Как видим, сравнивать драг даже с дабл-кликом по сложности можно только если считать сложность каждого маневра равной нулю.
Кстати, рекомендую еще вспомнить, что далеко не все пользователи проводят за компом 12-14 часов в сутки, как мы. Это все равно как сравнивать водительские навыки таксиста с навыками офисного служащего, который ездит утром туда, а вечером обратно. А некоторые пользователи — просто дачники, которые вообще выезжают раз в неделю, и то только в теплый сезон. Можно ли сказать, что "обратный полицейский разворот" столь же прост, как и обычный поворот с дороги во двор? Для некоторых — да.

Теперь давайте вспомним о том, что техническая сложность наступает только тогда, когда пользователь уже знает, что именно он собирается сделать.
Как мы только что обсудили, драг может оказаться очень сложным маневром (а может — и не очень, если а) объект для драга достаточно велик для уверенного подхвата (минимум 32*32), б) таргет-зона очень велика (например, окно експлорера открытое на 50% экрана) и по пути нет мин-ловушек (зон, куда можно бросить, но не стоит)).
Это означает, что пользователь не очень захочет пробовать его, не будучи уверен в результате.
Далее, Стивен Круг пишет, что наличие любого выбора для пользователя — зло. Допустим, у нас есть 8 интерфейсных элементов.
Во-первых, пользователь должен идентифицировать их все среди пестроты экрана. К счастью, для этого есть наработанные способы визуальной идентификации. Единообразие интерфейса очень сильно помогает в этом плане: человек легко выделяет знакомые образы, если они достаточно узнаваемы. Поэтому все кнопки на экране человек найдет легко. Синяя подчеркнутая надпись однозначно намекает на то, что это интерактивный текст, а не нарисованная на заборе статика. Шероховатости/грипы на разных элементах интерфейса подсказывают, что за них можно двигать.
Ок, после того, как идентификация произведена, пользователь должен выбрать тот элемент, который поможет ему в решении задачи. Для этого тоже есть целый арсенал средств и армия дизайнеров пиктограмм.
Далее надо понять, какой техникой воспользоваться для работы. Самым великим достижением винды я считаю правый клик. Возможность просмотреть список действий, которые можно совершить с объектом, да еще и узнать, какое именно ассоциировано с дабл-кликом — это очень удобно. Одиночный клик не всегда дает достаточно информации, а двойной рискует инициировать не то действие, которое надо. Так что человек либо кликает, либо дабл-кликает (если он уверен в своем выборе), либо делает правый клик и изучает меню.
В любом случае у него есть универсальный способ узнать, что и как можно сделать с объектом, без экспериментов.

Итак, как правило человеку достаточно выбрать среди 8 объектов, а затем (иногда) еще и среди ~10 глаголов.
Предположим, теперь у нас какое-то из действий скрыто за драг-н-дропом.
Теперь пользователю нужно
— догадаться, что действие может потребовать двух объектов из тех, которые он видит,
— выбрать эту пару из 64 вариантов
— проверить свои предположения

Никакого способа намекнуть пользователю, что объект А можно бросить на объект B, пока не изобретено. Все! Труба!
Еще раз подчеркиваю, что вся история современного GUI — это попытки выработать язык намеков, достаточный для того, чтобы человек мог читать UI. Мы достигли большого успеха — настолько большого, что продвинутые пользователи вроде нас с вами считают абсолютно естественными свои знания того, что и как работает. Это, кстати, тоже заблуждение. Большинство продвинутых пользователей наизусть знают только наиболее часто выполняемые из своих действий. Это становится видно, если попросить любого из нас рассказать, как сделать что-то мало-мальски нетипичное, не загядывая при этом в компьютер. Мы получаем 90% информации интерактивно, читая экран.

Это означает, что шансов построить вменяемый UI без такой обратной связи практически нет.
Итак, успешное взаимодействие с компьтером критическим образом зависит от трех возможностей:
— понять, что можно сделать, безо всякого взаимодействия (узнаваемые образы операбельных объектов и элементов управления)
— убедиться, что правильно понял, путем предварительного необязывающего взаимодействия:
-- наведение мышкой: hover-эффекты и хинты
-- левый клик: выделение выделимого объекта
-- правый клик: показ меню с доступными действиями
— легко отменить выполненное действие в случае ошибки (Ctrl-Z).

В большинстве случаев разработчикам вообще не надо об этом задумываться, потому что столь низкоуровневые вещи просто вшиты в используемые библиотеки. Но даже при выборе способа построения GUI из готовых элементов про это стоит знать.
Идиома drag-n-drop имеет огромные проблемы с первым пунктом, и существенные со вторым.
Поэтому если нет возможности отказаться от нее совсем, то нужно уделить огромное внимание реализации:
— для обхода первой проблемы просто необходимо написать в целевой зоне транспарант "перетащите сюда ... для того, чтобы их ..."
— для решения второй проблемы:
-- обязательно сделайте визуальную обратную связь в виде формы курсора (и не просто можно/нельзя! форма курсора "можно" должна как можно лучше отражать предстоящий эффект!)
-- обязательно сделайте поддержку правого драга с показом меню вариантов (например, Copy/Move/Create shortcut в эксплорере)
— обязательно реализуйте отмену действия для Drag-n-drop операций. Причем Ctrl-Z обязан корректно сработать независимо от того, какое из окон сейчас в фокусе — источник или приемник
-- неплохо было бы реализовать механизм а-ля смарт теги в офисе, т.е. возможность скорректировать действие пост-фактум. Меню смарт-тега должно дублировать меню правого драга + пункт "отменить".

Самое важное — это отмена. Именно потому, что действие технически сложно (а значит будет сопровождаться повышенным количеством ошибок), и слабоинтуитивно (значит велик риск того, что пользователь имел в виду вовсе не то, что выполнила программа). Если ресурсы ограничены, то ограничьтесь хорошей поддержкой отмены и предоставлением альтернативных вариантов (т.е. не должно быть интерфейсов, где драг-н-дроп — это единственный способ что-то сделать!). Если ресурсы еще более ограничены — выкиньте драг-н-дроп на помойку.