Интерфейс с drag-and-drop: как не запутать пользователя?

    Уверен, всем приходилось работать с интерфейсами drag-and-drop, а многим — разрабатывать ПО с таковыми. В большинстве случаев факт drop'а объекта-draggable на объект-target устанавливается по факту попадания координат курсора мыши в bounding box объекта-target в обработчке событий типа mouseUp, dragStop и прочих.

    Так работают почти все примеры, которые мне встречались. Но некоторое время назад, при реализации модуля интерактивного задания для образовательного ресурса, я столкнулся с тем, что такой подход не очень удобен. Основная причина — объекты-target существенно меньше объектов-draggable. Поэтому целится мышью неудбоно и утомительно. Таща крупный объектами-draggable, пользователь полностью перекрывает объект-target и не видит куда объект падает.


    image

    Соответственно было принято решение обрабатывать так:

    • если имеется контакт мыши с объектом-target, тогда drop будет строго на него
    • если нет, тогда ориентируемся на контакт bounding box объекта-draggable с bounding box объектов-target
      • если имеется контакт только с одним объектом-draggable — всё ясно, drop на него
      • а вот контакт с двумя и более — неоднозначная ситуация, куда делать drop — неясно

    В такой ситуации можно было бы задавать пользователю вопрос — куда он хочет drop'нуть объект. Это удобно, если объекты-target на экране как-то именованы (например, пронумерованы). Однако в нашем случае это излишнее усложнение интерфейса. Поэтому решили запрещать drop в таком случае и реагировать так, словно пользователь отпустил объект при отсутствии контакта.

    Подсветка.

    Также мы решили в случае однозначности подсвечивать контактирующий объект-target (условно) зеленым цветом, а в случае неоднозначности все контактирующие объекты-target — желтым. Таким образом мы даем пользователю подсказку — почему у него в одном случае drop происходит нормально, а в другом — нет.

    Однако! Напомню, что речь идет об учебном задании. Есть мнение, что такая подсветка может восприниматься как подсказка о правильности или неправильности попытки решения, а не о самом факте допустимости drop'а. При этом, позже к заданию добавили режим подсветки правильных ответов после вызова процедуры проверки. Если drop был на правильный объект-target, тогда объект-draggable подсвечивается зеленым, если нет — красным. И это стало сильно резонировать с подсветкой в процессе самого выполнения задания. Мы поменяли там цвета и стили подсветки, но насколько понятен такой интерфейс — неясно.

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

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

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

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Drag-and-drop: только мышь или области тоже?
    Поделиться публикацией

    Похожие публикации

    Комментарии 12
      0
       Мышь и контакт областей — всё верно! Насчёт подсветки: используйте прозрачность или жирность для подсказки target-объекта (цвета, действительно, пусть останутся для образовательной части)
        0
        Тут есть один момент. Хочется подсвечивать объекты-target и в случае коллизии. Например, цвета — оставим для подсветки ответов, а «потенциальный объект-target» в процессе drag-а будем оформлять, например, рисуя обводку. Жирную слошную у одного, если нет «коллизии», жирную пунктирную — у всех, с которыми «коллизия».

        Собственно, разные стили — да, хорошо. Но поскольку я так и не встретил нигде решения, которое при drag-and-drop использует контакт областей, подумалось — не фигню ли городим?
        +3
        1. Эм, а разве полупрозрачный draggable объект не помогает? Под ним можно разглядеть таргет.
        2. А UI никак не позволяет иметь таргет зоны больше, чем они визуально отрисованы?
          0
          1. В ряде случаев есть требование избегать прозрачности по максимуму. Кроме того, объекты-target небольшие даже в сравнении с пальцем
          2. В некоторых случаях они так близко натыканы, что — нет. Например, мы ориентируемся на рисунок-схему из печатного издания, должны его повторить. Мы либо выбрасываем какие-то объекты-target, либо используем подход, который я описал.
          Скажу больше — если неправильно расположить объекты-draggable, то визуально может получится каша. Объекты-draggable — блоки с текстом. После их drop'а оформление блока скрывается и остаётся только текст, который центрируется по центру объекта-target. Поэтому, если правильно расположить — будет копия того, что в печатном издании. А если неверно — то тексты могут пересекаться, заползать на рисунок и т.п.

          В общем, это тот случай, когда мы вынуждены «плясать» от имеющегося оформления.
          Если делаем подобное с нуля — конечно закладываем большие области, с оформлением или как вы указали.
            0
            Драг-энд-дроп весьма сложное действие для UX.
            Если у вас UI тесное и мелкое, то явно надо додумывать альтернативные таргет зоны (которые конечно не видно в zero-state).

            image
              0
              Да, альтренативные зоны — возможно. С их визуализацией при контакте?

              Кстати! Я упустил еще один важный момент. Если мы пускаем интерактивн на доске — то это чертова куча дюймов, которые надо тащить объект. Поэтому изначально идея об использовании пересечений по областям пришла оттуда — чтобы меньше тянуться и метаться у интерактивной доски.
          0
          При начале drag-движения можно сместить drag-объект относительно курсора таким образом, чтобы его левый верхний угол совпадал с левым верхним углом курсора.
          И вообще, почему этот топик здесь, а не в QA?
            +1
            Да, можно попробовать…
            Насчет QA — не подумал. Хотел на Тостер, но мне важен не конкретный ответ, а мнение многих — поэтому добавил опрос.
            +1
            Привет коллеге по e-learning! :)

            Если руководствоваться Jquery UI как best practice, то есть 4 варианта:
            «fit»: полное совпадение элемента с таргетом
            «intersect»: пересечение на 50%
            «touch»: любое пересечение
            «pointer»: попадание мышкой

            Решение «спорных» кейсов — хорошее, мы тоже так делали.

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

            а) драгается не элемент, а его «репрезентация», например, иконка, или его номер, или уменьшенный тамбнейл. Это позволяет уменьшить размер перетаскиваемого объекта и решить вашу проблему. Пример (даже два) «от больших мальчиков»: перетаскивание 20+ файлов в Win 7 или OS X

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

            в) отказаться от перетаскивания вообще и заменить его на любой из сотен видов интерактивностей. Instructional value от этого не пострадает, поверьте, оно не в драг-н-дропах кроется.
              0
              Большое спасибо за ценный опыт и готовность им делиться!

              Подумаю насчет «intersect». Вариант с перетаскиванием «репрезентации» — тоже очень интересен. Согласен с примерами.

              С рисованием линий — 50/50. Тут конечно линии временные, но, все-таки будет перекликаться с типом заданий на установление соответствий, где линии как раз и рисуются (но не временные, конечно). Хотя, смотря как обыграть анимацию по завершению действия.
              Но есть еще момент — подложки в таких задания часто сами содержат линии — линии выносок подписей от рисунков, линии на схемах… Но, всё же, дверюсь вашему опыту — попробуем.

              Отказаться от перетаскивания вообще — не можем. Есть задача разнообразить интерактивы именно с точки зрения UX. А не было бы — свели бы всё к спискам, чекбоксам и полям ввода с клавиатуры. Можем конечно в некоторых случаях. Но обычно сложные случаи мы трансформируем в серию заданий на одной подложке.

              Кроме того, наша целевая аудитория — школа. А в начальной всё усугубляется :)

              Не уловил смысл «Instructional value». Имеется ввиду суть задания?
                0
                Хм. В начальной школе вы хотите чтобы ученики перетаскивали объекты достаточно точно? Не слишком много от них требуете?

                Если у вас заранее известно, куда должен попасть объект (эдакий пазл) — проверяйте расстояние с требуемой позицией, если оно меньше — ставьте туда.
                Если нужно, например, разложить объекты по карзинкам — делайте карзинки большими.
                В конце концов можно просто искать площадь пересечения BB и относить объект к тому, где это пересечение максимально (а если у вас может влезать несколько под перетаскиваемый объект — то к ближайшему к мышке. Но если такая ситуация не избежна — стоит уменьшать или делать полупрозрачным или искать принципиально другие пути).
                Еще есть способ один — просто проверять по верхнему левому углу и подсвечивать «тень», куда станет перетаскиваемый объект при отпускании.
                  0
                  Нет, как раз в начальной школе мы этого и не требуем. И вообще — не требуем, что подразумевается в статье. Мы хотим соблюсти иногда противоречивые требования: сделать раскладку элементов как в печатном издании и сделать UX понятным и удобным.

                  Насчёт «пересечение максимально» — согласен, как вариант. Расстояние до позиции — уже спорно, неоднозначности могут быть.
                  Иногда неоднозначность только визуально определяется пользователем. Поэтому мы обязательно делаем подсветку. Но… в общем, в тексте статьи я описал вариации.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое