M>>И так далее. Иногда пытаешься выполнить 1, а выполняется 3. Как мне кажется, история закрытых окон в Опере появилась именно благодаря этому. В общем, как уже было замечено, жесты — это "фича для гиков", простому юзеру она не нужна.

A>А если попробовать вот это:

A>Right-click left-click — страницу назад
A>left-click right-click — страницу вперед

Самая удобная фича в Опере. Крепко уходит в подсознание и ее жутко не хватает в других программах

M>>Дабл-клик уже попадает в категорию "сложный для пользователя". Drag'n'drop является максимально сложной для пользователя операцией и его следует вообще избегать. А жесты мышкой — это вообще заоблачно.
А>Хотел бы я узнать IQ пользователя, для которого сложно дабл-клик. Мне кажеться, что пытаться ориентировать софт на вот этих http://lenta.ru/news/2005/12/26/reading/ бессмысленно, врятли они осилят что-то кроме косынки...

Во всех советах по юзабилити эта сложность так определяется. Советую нати пользователя-новичка и проследить то, как он делает те самые дабл-клики и драг-н-дропы. Очень расширяет сознание на то, как это, на самом деле, сложно

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

M>Во всех советах по юзабилити эта сложность так определяется. Советую нати пользователя-новичка и проследить то, как он делает те самые дабл-клики и драг-н-дропы. Очень расширяет сознание на то, как это, на самом деле, сложно

Общее утверждение, опровергается одним примером (с) Аристотель. Я приведу три.

В соседней со мной комнате живёт бабушка, которой год назад купили комп. Она не способна уже в принципе (85 лет, вся жизнь в деревне) понять что такое папки и файлы, она спрашивала про ворд — "а не кончится ли в нём бумага?", она знает только два места — мои документы и рабочий стол и не умеет использовать для удаления символов кнопку делит, а только бэкспейс, но даблклик на своих текстах (она пишет детские сказки) и драг-н-дроп между этими местами умеет делать не хуже меня. И это при старческом маразме и явно больной голове — стандартное "вы хотите меня отравить" и "вы урали мои деньги"...

У моих друзей (муж и жена) есть сын. Ему три с половиной годика. Даблклик на своей любимой игре змейка научился делать сам, без подсказок, когда понял что с одного она не включается. Теперь делает даблклик везде, так же не хуже меня.

Мой бывшый одноклассник — типичный "бык". Шкаф 2х2, IQ отрицательный Чтобы быть крутым, купил себе крутой ноутбук. Запускать игры даблкликом и копировать файлы (фотки там, картинки, мувики) умеет на 5 баллов. "Обучение" заняло 2 минуты под пивко. Объяснил, что внутри бука есть коробочка, где всё лежит, и если он хочет чтобы у него чегото осталось после вынимания компакт-диска, надо это что-то взять и вон в ту коробочку перетащить. Создавать папки научился сам, когда загадил хард.

Вывод — это сложно наверное только для людей с серьёзными дисфункциями головного мозга. Серьёзнее, чем у соседки бабушки.

Здравствуйте, <Аноним>, Вы писали:

А>Вывод — это сложно наверное только для людей с серьёзными дисфункциями головного мозга. Серьёзнее, чем у соседки бабушки.
И вот зачем, спрашивается, всякие Нильсены проводят дорогостоящие исследования и пишут диссертации на тему UI? Вон — аноним одним махом опроверг все их бумажные построения. Раз три человека могут — значит могут все.

Увы, даже если ты приведешь еще троих, статистики это не изменит. Я лично встречал примеры, когда совершенно опытный программист с IQ 130 в расцвете лет матерится вслух потому, что он потащил группу файлов через весь экран и нечаянно уронил их по пути. А теперь не может найти, т.к. упали они куда-то в дерево експлорера, неудачно оказавшееся на пути.
Одного такого примера достаточно, чтобы понять преимущество интерфейса, не требующего эквилибристики.

Даже Манделл, самый упертый проповедник "таскаемых иконочек" и тот признает, что не знает способа намекнуть пользователю о наличии драг-н-дропа. Нормальный пользователь не будет экспериментировать с перетаскиванием сотни объектов друг на друга для выяснения, кто совместим, кто не совместим. Если это не квест, для которого он специально запланировал выходные.
Перетаскивание файлов из папки в папку освоили все.
А вот, кстати, про возможность дропнуть файл из експлорера в окно Visual Studio для его открытия я узнал совершенно случайно в Москве, в редакции RSDN — когда Влад при мне проделал такую манипуляцию.

S>А вот, кстати, про возможность дропнуть файл из експлорера в окно Visual Studio для его открытия я узнал совершенно случайно в Москве, в редакции RSDN — когда Влад при мне проделал такую манипуляцию.

Причем подобная функциональность еще и по разному в разных приложениях реализована.

Например,
Любой (текстовый?) файл, перетянутый в рабочую область Visual Studio, будет открыт средой.

Любой (текстовый?) файл, перетянутый в пустую рабочую область Dreamweaver, будет открыт средой.
Любой (текстовый?) файл, перетянутый поверх уже открытого файла в Dreamweaver, будет игнорирован средой.
Любой (текстовый?) файл, перетянутый поверх тулбаров, меню в Dreamweaver, будет открыт средой.

Но при этом у той же Macromedia в HomeSite любой файл, перетянутый поверх уже открытого файла, организует в этом файле гиперссылку на перетягиваемый файл.


Или еще примеры.

Перетягивание файлов вверх/вниз в/из папок в Project Explorer в Visual Studio не влечет за собой перемещение файлов внутри файловой системы.
Зато в Navigator'e среды Eclipse, который выглядит ну абсолютно точно также, любые манипуляции с файлом отражаются и в файловой системе тоже.

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

S>И вот зачем, спрашивается, всякие Нильсены проводят дорогостоящие исследования и пишут диссертации на тему UI? Вон — аноним одним махом опроверг все их бумажные построения. Раз три человека могут — значит могут все.
С точки зрения логики, любой один из трёх примеров опровергает общее утверждение "драг-н-дроп это сложно". Про все бумажные построения я не говорил, это Вы придумали. Выделенное, очевидно, неверно, и так же придумано Вами.

S>Увы, даже если ты приведешь еще троих, статистики это не изменит. Я лично встречал примеры, когда совершенно опытный программист с IQ 130 в расцвете лет матерится вслух потому, что он потащил группу файлов через весь экран и нечаянно уронил их по пути. А теперь не может найти, т.к. упали они куда-то в дерево експлорера, неудачно оказавшееся на пути.
Мы все с детсва обучены пить чай из чашки и мастерски владеем этим искусством, делая всё необходимое на автомате. Тысячи лет наши предки пили жидкости из ёмкостей и это наверное у нас уже в генах. Но не смотря на это, мы частенько бьём чашки, проливаем чай, обжигаем глотку, и совершаем множество других нелепых и дурацких ошибок. По этим ошибкам нельзя судить ни о нашем умении использовать ёмкости для питья, ни о сложности "обучения" этому. Ваш пример бессмысленен в контексте спора, т.к. ничего не опровергает и не доказывает.

S>Даже Манделл, самый упертый проповедник "таскаемых иконочек" и тот признает, что не знает способа намекнуть пользователю о наличии драг-н-дропа. Нормальный пользователь не будет экспериментировать с перетаскиванием сотни объектов друг на друга для выяснения, кто совместим, кто не совместим. Если это не квест, для которого он специально запланировал выходные.
Не спорю, операция не вполне очевидная. Но неочевидность никак не связана со сложностью. Это элементарная операция, и любому нормальному человеку достаточно показать один раз как это делается.

S>Перетаскивание файлов из папки в папку освоили все.
S>А вот, кстати, про возможность дропнуть файл из експлорера в окно Visual Studio для его открытия я узнал совершенно случайно в Москве, в редакции RSDN — когда Влад при мне проделал такую манипуляцию.
Про возможность дропнуть файл в приложение для открытия я догадался сам, благо так можно делать почти везде. Архиваторы, браузеры, всякие фотошопы и иже с ними это поддерживают. Это стандарт де факто. Мало того, я расстраиваюсь, когда встречаюсь с не поддерживающими это дело приложениями.
А вот знали ли вы про возможность нажатием ^C скопировать содержимое любого мессаджбокса? Я нет, пока не прочитал об этом у Рихтера, который в свою очередь узнал это от мелкомягких разработчиков. Совершенно не очевидная, но очень простая операция.

Только как это с темой разговора всё связано? Мне кажеться, пора выделять в отдельную ветку или завязывать, а то похерят за жестокий оффтоп.. Да, если Вас смущает моя анонимность, меня зовут Александр, можно на ты, и вообще... регистрироваться просто лениво.

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

M>Перетягивание файлов вверх/вниз в/из папок в Project Explorer в Visual Studio не влечет за собой перемещение файлов внутри файловой системы.
Я тебе больше скажу... То что ты описал касается С++ных проектов. А если тоже самое проделать с проектом на C# то изменения отразятся в файловой системе.

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

Интересна логика мышления человека, тянущего файл на тулбар вместо области редактирования. Понятно ещё если на кнопку открыть файл, а вот просто на тулбар — не ясно.

M>Но при этом у той же Macromedia в HomeSite любой файл, перетянутый поверх уже открытого файла, организует в этом файле гиперссылку на перетягиваемый файл.
Помоему, всё очень просто. Что мы делаем? В первом случае, мы тянем файл в область редактирования этих файлов, что приводит к его открытию для редактирования. Во втором, мы тянем файл в _редактируемый_документ_. Что приводит к вставке файла в документ. Всё совершенно однозначно, какие могут быть сомнения?

M>Перетягивание файлов вверх/вниз в/из папок в Project Explorer в Visual Studio не влечет за собой перемещение файлов внутри файловой системы.
Смотря что за проект. Если C++ то не ведёт, если C# или VB .NET то ведёт. Это очевидно следует из устройсва проекта C++ и C#/VB. Если вы программист, и создаёте проекты в среде разработки, будьте добры поинтересоваться что же такое вы там создаёте.

Не даром в автошколах учат не только вождению и правилам, а ещё и устройству автомобиля. Чтобы человек понимал что делает. Если же вы хотите делать то незнаю что но чтоб всё было как везде и правильно, то так не будет никогда... И виноваты в этом конечно же кривые ручки программистов, не способные сваять нормальный интерфейс

А>Интересна логика мышления человека, тянущего файл на тулбар вместо области редактирования. Понятно ещё если на кнопку открыть файл, а вот просто на тулбар — не ясно.

Это вопросы к создателям Dreamweaver, это они такое придумали, не я.

M>>Но при этом у той же Macromedia в HomeSite любой файл, перетянутый поверх уже открытого файла, организует в этом файле гиперссылку на перетягиваемый файл.
А>Помоему, всё очень просто. Что мы делаем? В первом случае, мы тянем файл в область редактирования этих файлов, что приводит к его открытию для редактирования. Во втором, мы тянем файл в _редактируемый_документ_. Что приводит к вставке файла в документ. Всё совершенно однозначно, какие могут быть сомнения?

Для меня это — рабочая область, от которой я ожидаю одинакового поведения на одинаковые действия.

M>>Перетягивание файлов вверх/вниз в/из папок в Project Explorer в Visual Studio не влечет за собой перемещение файлов внутри файловой системы.
А>Смотря что за проект. Если C++ то не ведёт, если C# или VB .NET то ведёт. Это очевидно следует из устройсва проекта C++ и C#/VB. Если вы программист, и создаёте проекты в среде разработки, будьте добры поинтересоваться что же такое вы там создаёте.

я ожидаю одинакового поведения на одинаковые действия.

А>Не даром в автошколах учат не только вождению и правилам, а ещё и устройству автомобиля. Чтобы человек понимал что делает. Если же вы хотите делать то незнаю что но чтоб всё было как везде и правильно, то так не будет никогда... И виноваты в этом конечно же кривые ручки программистов, не способные сваять нормальный интерфейс

Ну естественно

Здравствуйте, Аноним, Вы писали:

А> Да, если Вас смущает моя анонимность, меня зовут Александр, можно на ты, и вообще... регистрироваться просто лениво.

Во! Теперь я всех анонимов буду называть Александр.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Чипсет, Вы писали:

Ч>>Здравствуйте все!
Ч>>У меня вот возник вопрос, почему не используют ещё этот гениальный способ управления все производители программного обеспечения, где Microsoft со своими патентами и вообще почему сабжу уделяеться так мало внимания?
Ч>>

Кё>А у меня есть привычка всё время пока читаю текст кликать мышкой везде, выделять его, дергать туда-сюда какие-нибудь элементы, залазить в окно About... С жестами в опере из-за этого первоначально были проблемы

А я так книжки читаю — отрываю маленькие кусочки от краёв, чиркаю маркером, выворачиваю обложку. Проблемы с библиотекаршами, извергом кличут...

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

Кё>>А у меня есть привычка всё время пока читаю текст кликать мышкой везде, выделять его, дергать туда-сюда какие-нибудь элементы, залазить в окно About... С жестами в опере из-за этого первоначально были проблемы

В>А я так книжки читаю — отрываю маленькие кусочки от краёв, чиркаю маркером, выворачиваю обложку. Проблемы с библиотекаршами, извергом кличут...

Читай на компе, спасай деревья!

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

M>я ожидаю одинакового поведения на одинаковые действия.

В общем-то, да. Вы ожидаете одного, но как уже сказали выше даже если вы наберете еще троих таких же как и вы — это не показатель, так как я могу ожидать другого, а мой сосед и вовсе третьего. А соседка — она вовсе ниче не ожидает так как попросту не пользует ДнД...

Вот человек выше сказал что для него новостью было то, что файл брошенный в Студию откроется ею. А между прочим это *вроде* один из гайдлайнов от МС и одно из условий получения "знака отличия" ВинЛого.
Наверняка будет новым и то, что файл брошенный на ярлык программы запустит эту программу и откроет файл (ок, правильнеее не откроет, а совершит дефолтное действие для данного файла).

А для того, чтобы не гадать и не выдумывать себе квесты на день-второй с перетягиванием всего на все существуют мануалы (если существуют, но это уже другой вопрос). Да, знаю, пользователи не читают мануалы. Но не все интерфейсы будут одинаково интуитивны для всех пользователей данной программы.

[skip]
S>А для того, чтобы не гадать и не выдумывать себе квесты на день-второй с перетягиванием всего на все существуют мануалы (если существуют, но это уже другой вопрос). Да, знаю, пользователи не читают мануалы. Но не все интерфейсы будут одинаково интуитивны для всех пользователей данной программы.

то есть, вернулись к исходному

Автор: Mamut
Дата: 09.01.06

— к тому, что drag'n'drop является сложной и неинтуитивной для пользователя операцией

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

А в общем, согласен с пред. постами: это не сложно, точно так же как и обращение с мышью (сперва некоторые пользователи не могут уловить как движение руки соотносится с движением курсора на экране и постоянно смотрят на мышь). Интуитивно ли это? Ну, не более чем дабл клик или клик, если вы не знакомы с интерфейсом.

Здравствуйте, 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 обязан корректно сработать независимо от того, какое из окон сейчас в фокусе — источник или приемник
-- неплохо было бы реализовать механизм а-ля смарт теги в офисе, т.е. возможность скорректировать действие пост-фактум. Меню смарт-тега должно дублировать меню правого драга + пункт "отменить".

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

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

Несколько ошибок — трудно писать длинные тексты
...
S>- удерживая его на месте, нажать и отпустить кнопку мыши. К счастью, в винде принято считать, что отпускание можно выполнять в любом месте той же активной зоны, так что немножко сдвинуть при клике нестрашно. Таймаута также нет, так что клик можно выполнять в любом темпе.
(Пропущенный текст вставлен)
...
S>Далеко не все драг-н-дроп системы поддерживают отмену дропа
(ошибка)

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

M>Советую нати пользователя-новичка и проследить то, как он делает те самые дабл-клики и драг-н-дропы. Очень расширяет сознание на то, как это, на самом деле, сложно

Угу, я пока собственными глазами не увидел, не верил — для человека по началу не удобно, что у мышки которая лежит справа, есть какая-то левая кнопка и правая кнопка.

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

Ч>Здравствуйте все!
Ч>У меня вот возник вопрос, почему не используют ещё этот гениальный способ управления все производители программного обеспечения, где Microsoft со своими патентами и вообще почему сабжу уделяеться так мало внимания?
Ч>

Гениальное.... Как по мне, то нет. Почему? А потому что это очередная попытка решить взаимодействие пользователя и компьютера через филейную часть антропоморфного дендромутанта. Наиболее удобным является взаимодействие с пк при помощи тех же действий что и в реальной жизни. Как-то прочитал о нововведении в Маках. Там операция drag and drop была изменена с помощью новой мыши: что мы делаем когда перетаскиваем предмет в реальной жизни? мы его берём и тащим. Так и в Маке: навели курсор СХАТИЛИ мышь за бока и потянули. Как показала статистика, для новых пользователей это было куда естественнее чем хватать кнопкой.
А жесты мышью... Ну а если я говорить привык? Для людей, которые к сожалению лишены этой возможности, подобный метод может и будет более естественнен (хотя опять таки врядли, у них жестов пальцами больше чем жестами рук), то для меня и мне подобным он неестественнен. Более того этим жестам я предпочту комбинации клавиш, потому как если я нажал Ctrl+C, то я знаю, что произошло копирование в буфер обмена. А если я курсором сделал петлю Нестерова и нечаянно дёрнул её немного вбок и получил не ту операцию, то это далеко не то, что хотелось.

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

S>Я смотрю, ничто не останавливает любителей спорить с очевидным.

Не думаю что мой спор будет отличаться от вашего, в случае его наличия. Что есть очевидно? Если вы говорите что даже матерый программер с высоким АйК"ю бывает недотягивает или промахивается (хотя то, что он программер или его уровень АйК"ю мне кажется мало говорит о способности владеть мышкой) — то это значит "ДнД очевидно тяжел", если другой говорит что секретарши тягают лучше матерых программеров — то это напротив не говорит что "ДнД легок". Почему? Или я не понял что вы имели в виду под очевидным?

S>Ок, продолжим. Ваша фраза "ну, не более чем" либо является фигурой речи, либо выдает ваше полное незнакомство с предметом.

Я, видимо так же, как и вы знаком с работами Карда, Новелла и др.

S>Итак, рассмотрим сначала техническую сложность.
S>1. Клик: нужно
(...скип...)

1 — мне это известно
2 — интервал между первым и вторым кликом для распознания как дабл-клик настраиваем. 500 мс — частный случай. Так же как и зона смещения. Вы говорите "Важно правильно выбрать усилие нажатия на кнопку и его направление, чтобы не сдвинуть мышь." — но мышь сдвигать можно!
3 — добавлю, что при ДнД сложность также выражается расстоянием.

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

Есть Reset to Default. Если не подходит — сами знаете что есть Customize.

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

Это смотря чем работники занимаются, правда? Вы считаете разработчиков самой тесно связанной с компутером профессией (в плане работы с ГУИ)? Сегодня? Думаю вы согласитесь что дизайнер и инженер с трекболом имеет все шансы догнать и обогнать матерого разработчика.
О чем я хотел сказать: если есть мотивация — пользователь любой осилит это. И даже самый сложный ДнД. Но только если конечно будет знать об этой возможности.
И конечно же есть люди, которые просто не расположены к работе с мышей, точно так же как некоторые не способны освоить вождение, так как теряются в "интерфейсе" машины. Но ведь брать таких людей за нулевую точку отсчета не правильно (при сравнении).

S>Теперь давайте вспомним о том, что техническая сложность наступает только тогда, когда пользователь уже знает, что именно он собирается сделать.
S>Как мы только что обсудили, драг может оказаться очень сложным маневром (а может — и не очень, если а) объект для драга достаточно велик для уверенного подхвата (минимум 32*32), б) таргет-зона очень велика (например, окно експлорера открытое на 50% экрана) и по пути нет мин-ловушек (зон, куда можно бросить, но не стоит)).
S>Это означает, что пользователь не очень захочет пробовать его, не будучи уверен в результате.

Вот именно, читайте выше о мотивации. Если будет уверен что ему это надо — сделает. Очевидно, что если он не владеет такой информацией — оценить нужжно ему это или нет нельзя.

S>Далее, Стивен Круг пишет, что наличие любого выбора для пользователя — зло. Допустим, у нас есть 8 интерфейсных элементов.
(скип)
S>В любом случае у него есть универсальный способ узнать, что и как можно сделать с объектом, без экспериментов.

Согласен: понимание работы системы (ментальная модель), метафоры, подсказки, следование стандартам.

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

... или не догадываться, а знать это.

S>Никакого способа намекнуть пользователю, что объект А можно бросить на объект B, пока не изобретено. Все! Труба!

Вспомним Корзину на Рабочем столе, сам Рабочий стол с документами... Или это не то?

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

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

S>В большинстве случаев разработчикам вообще не надо об этом задумываться, потому что столь низкоуровневые вещи просто вшиты в используемые библиотеки. Но даже при выборе способа построения GUI из готовых элементов про это стоит знать.
S>Идиома drag-n-drop имеет огромные проблемы с первым пунктом, и существенные со вторым.

Т.е. дабл-клике более узнаваем "безо всякого взаимодействия" чем ДнД

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

Имхо, интуитивны человеку совсем другие вещи, никак не дабл-клики и ДнД...

И наконец, по поводу жестов: вы писали выше "Жесты второй проблемы лишены" имея в виду судя по этому

2. являясь по сути аналогом горячих клавиш, они при этом более сложны как по запоминанию так и по воспроизведению (что логично, т.к. мышь менее выразительна чем клавиатура).

легкость воспроизведения: "Одно дело — попасть в кнопочку 16*16, да еще и при клике не сдвинуть мышу, а другое — надавив кнопку дернуть вправо-влево".
Так вот: по аналогии с ДНД нужно ведь точе зажать кнопку мыши, и движения должны быть более выверены и точны чем в случае с ДнД. Второе. как и в случае ДнД (ошибка при дропе) ошибка в траектории — те же последствия, а может и хуже, так как может быть сложно проследить как же распознался ваш жест и что сделала программа.

Мне интересна эта тема. Жесты имеют право жить. Как и все остальные способы. Я в частности занимался исследованием внедрения управления жестами в layout-дизайнеры...