Comments 79
по моему что-то похожее реализовано в новой почте яндекса
Лично мне было бы такое не удобно.
Я бы предпочел, чтобы при движении над таблицей кнопки выносились рядом в горизонтальном ряде.
---
---ччч
---
ччч - это кнопки
Так просто сразу понятно, к чему они относятся.
При нажатии - запоминаются.
Я бы предпочел, чтобы при движении над таблицей кнопки выносились рядом в горизонтальном ряде.
---
---ччч
---
ччч - это кнопки
Так просто сразу понятно, к чему они относятся.
При нажатии - запоминаются.
Не совсем понимаю выражение "при движении над таблицей". Если речь идёт о наведении мыши на элементы, то это описано в решении номер 1. Мне кажется, что в таком подходе есть некоторое замешательство со стороны пользователя. Тоесть сначала надо навести и лишь потом можно посмотреть, что можно сделать.
http://artgorbunov.ru/bb/soviet/20070604… совсем недавно у Горбунова эта тема поднималась.
Думал, ремейк его обсуждений.
Думал, ремейк его обсуждений.
Это можно встретить, например, у last.fm.
Первый вариант хорош тем, что предоставляет возможность без доп. действий отредактировать нужную единичную запись (что, впрочем, и бывает нужно куда чаще при работе со списком таблиц, нежели групповая операция), все действия видны и очевидны. Для группы элементов – селект внизу списка. Страдает повторениями, но это скорее не извращения, а элементарная избыточность в ущерб визуалу.
Второй вариант хороший. Однако он не подразумевает работы с группой элементов. Да и не табличный он, как в первом примере. Его применить, например, к тому же списку таблиц будет не очень удобно. Плюсом обязателен JavaScript (по крайней мере, для IE 6-), но, думаю, это уже никого не беспокоит.
"Решение 2. Моё (по крайней мере пока больше нигде не видел)"
Ну как же, это аля "With selected", только сделано не списком, а кнопками, более эстетично :).
Это аналогия стандартного десктоп-приложения с панелью инструментов: выбираем группу, щелкаем на соответствующую операцию. Но что чтобы быстро отредактировать единичную запись, нужно совершить как минимум 2 клика.
В целом, сказать что лучше, что хуже нельзя, все зависит от конкретной ситуации и формата данных, с какими работает пользователь.
В Вашем варианте для быстрого единичного редактировани можно предусмотреть возможность двойного клика на записи.
Второй вариант хороший. Однако он не подразумевает работы с группой элементов. Да и не табличный он, как в первом примере. Его применить, например, к тому же списку таблиц будет не очень удобно. Плюсом обязателен JavaScript (по крайней мере, для IE 6-), но, думаю, это уже никого не беспокоит.
"Решение 2. Моё (по крайней мере пока больше нигде не видел)"
Ну как же, это аля "With selected", только сделано не списком, а кнопками, более эстетично :).
Это аналогия стандартного десктоп-приложения с панелью инструментов: выбираем группу, щелкаем на соответствующую операцию. Но что чтобы быстро отредактировать единичную запись, нужно совершить как минимум 2 клика.
В целом, сказать что лучше, что хуже нельзя, все зависит от конкретной ситуации и формата данных, с какими работает пользователь.
В Вашем варианте для быстрого единичного редактировани можно предусмотреть возможность двойного клика на записи.
Идея с двойным кликом понравилась. Спасибо.
Стоит много подумать, а действительно ли уместны групповые операции для конкретного случая. Характерный пример который можно привести - это удаление объектов из списка: отметили чекбоксами - удалили отмеченное.
Как должен думать человек?
1. принять решение о самой операции "Нужно удалить некоторые записи"
2. отмечает те из них, которые нужно удалить
3. нажать на кнопку "удалить отмеченные".
Улучшение удобства для такого варианта может заключаться, например, в том, чтобы убрать групповую операцию "удалить" вместе с чекбоксами и оставить напротив каждой записи кнопку "удалить", которая умеет удалять через ajax и перерисовывать страницу (убрать объект и перерисовать различные счетчики, возможно пейджер) без перезагрузки.
Загроможение списка одинаковыми контролами может компенсироваться так, как это реализовано на http://lenta.yandex.ru - то есть подсвечивать только относящийся к объекту в фокусе контрол, а остальные сделать менее заметными.
Понятно, что такое решение более трудоемко с точки зрения проектирования и программирования однако имеет очевидные плюсы: минимизация интерфейса за счет убирания групповых операций и возмости для пользователя принять решение в контексте конкретного объекта, а не "запомненной" функции.
Как должен думать человек?
1. принять решение о самой операции "Нужно удалить некоторые записи"
2. отмечает те из них, которые нужно удалить
3. нажать на кнопку "удалить отмеченные".
Улучшение удобства для такого варианта может заключаться, например, в том, чтобы убрать групповую операцию "удалить" вместе с чекбоксами и оставить напротив каждой записи кнопку "удалить", которая умеет удалять через ajax и перерисовывать страницу (убрать объект и перерисовать различные счетчики, возможно пейджер) без перезагрузки.
Загроможение списка одинаковыми контролами может компенсироваться так, как это реализовано на http://lenta.yandex.ru - то есть подсвечивать только относящийся к объекту в фокусе контрол, а остальные сделать менее заметными.
Понятно, что такое решение более трудоемко с точки зрения проектирования и программирования однако имеет очевидные плюсы: минимизация интерфейса за счет убирания групповых операций и возмости для пользователя принять решение в контексте конкретного объекта, а не "запомненной" функции.
Т.е. вы предлагаете в таблице, где 50+ записей, не делать групповой операции, нажимая на каждую по отдельности? А если мне нужно удалить 45 из них? Застрелиться :)
К тому же, эти же чекбоксы могут применяться не только для удаления, но и для большего количества групповых операций. Например: удалить, скопировать, вырезать, спрятать и прочее-прочее.
К тому же, эти же чекбоксы могут применяться не только для удаления, но и для большего количества групповых операций. Например: удалить, скопировать, вырезать, спрятать и прочее-прочее.
вы в какой момент принимаете решение о том чтобы удалить, скопировать, вырезать, спрятать и прочее-прочее? подозреваю, что глядя на запись. если не глядя - то вам все равно. А случай который вы описали характерен для папки "Спам" - там есть групповая операция "Удалить ваще все"
При чем тут ящик с письмами?
Не надо к частному переходить, не тот случай.
Не надо к частному переходить, не тот случай.
в какой момент вы принимаете решение?
Я принимаю решение, как вы и сказали, глядя на запись. Точнее, я отмечаю запись для операции, глядя на нее. Решение я принял до того, как отметить нужные записи или после того, как прочел первую и, например, понял, что она мне не нужна и может быть есть еще несколько подобных – я начинаю их выделять, зная, какую операцию я произведу над ними.
Но не в этом суть. Возможно, я не понял вас.
Вы предлагали убрать групповую операцию удалить + убрать чекбоксы, реализовав появление кнопки операции для объекта, находящегося в локусе внимания. Тогда как в этом случае быть с другими групповыми операциями, если они требуются для группы объектов? Поясните, пожалуйста.
Но не в этом суть. Возможно, я не понял вас.
Вы предлагали убрать групповую операцию удалить + убрать чекбоксы, реализовав появление кнопки операции для объекта, находящегося в локусе внимания. Тогда как в этом случае быть с другими групповыми операциями, если они требуются для группы объектов? Поясните, пожалуйста.
вы смотрите на запись и принимаете решение: нужна она вам или не нужна. если не нужна - тут же удаляете. Это же очень просто.
Групповая операция для удаления нужна в первую очередь для экономии трафика и времени на перезагрузку страницы. В данном случае этот аспект исключается применением аякса.
Про другие групповые операции нужно думать отдельно. Я привел пример операции удаления как иллюстрирующий мою мысль. Мысль об отсутствии необходимости отмечать прежде чем удалять. Приведите реальный пример групповой операции и можно подумать, стоит ли ее заменить индивидуальным действием, или не стоит.
Я стараюсь рассматривать конкретные случаи, так как для них проще выработать решение чем для абстрактной ситуации. Тем более не хочу разговаривать об абстракциях, что у нас с вами появляются заведомо разные контексты и мы говорим о разных вещах. Ассиметричный дуализм языкового знака, проще говоря =)
Групповая операция для удаления нужна в первую очередь для экономии трафика и времени на перезагрузку страницы. В данном случае этот аспект исключается применением аякса.
Про другие групповые операции нужно думать отдельно. Я привел пример операции удаления как иллюстрирующий мою мысль. Мысль об отсутствии необходимости отмечать прежде чем удалять. Приведите реальный пример групповой операции и можно подумать, стоит ли ее заменить индивидуальным действием, или не стоит.
Я стараюсь рассматривать конкретные случаи, так как для них проще выработать решение чем для абстрактной ситуации. Тем более не хочу разговаривать об абстракциях, что у нас с вами появляются заведомо разные контексты и мы говорим о разных вещах. Ассиметричный дуализм языкового знака, проще говоря =)
"в первую очередь для экономии трафика"
Не согласен. Групповая операция, прежде всего, для удобства пользователя и экономии его времени, а не трафика. Прошли те времена, когда модем в 56 бод считался роскошью ;) К тому же, никто не мешает удалить группу элементов через этот же аякс.
Не могу не согласиться, что при наличии 20-30 записей, из которых обычно нужно удалить в среднем 2-5, групповое удаление ни к чему. Но, опять же, все решает ситуация. Как быть, скажем, при работе через мобильник (кто-то тут упоминал про него)?
Привести пример... могу полуабстрактный пока: удаление списка элементов, где обычно 50-70% требуют удаления. Индивидуальной пользоваться надоест очень быстро.
Не согласен. Групповая операция, прежде всего, для удобства пользователя и экономии его времени, а не трафика. Прошли те времена, когда модем в 56 бод считался роскошью ;) К тому же, никто не мешает удалить группу элементов через этот же аякс.
Не могу не согласиться, что при наличии 20-30 записей, из которых обычно нужно удалить в среднем 2-5, групповое удаление ни к чему. Но, опять же, все решает ситуация. Как быть, скажем, при работе через мобильник (кто-то тут упоминал про него)?
Привести пример... могу полуабстрактный пока: удаление списка элементов, где обычно 50-70% требуют удаления. Индивидуальной пользоваться надоест очень быстро.
интересно... в чем удобство сначала ткнуть мышкой в чекбокс, а потом нажать удалить, по сравнению с моментальным удалением, а? Объясните мне, пожалуйста. Где экономия времени и дейсвий пользователя?
Мне кажется что вы не поняли суть замечания.
Моментальное удаление удобно в некоторых узких моментах, да.
Но только тогда, когда:
1. Есть ТОЛЬКО удаление и нет других групповый операций. Если есть другие групповые операции, то убрать чекбокс нельзя. В этом случае как предлагаете быть с удалением?
2. Если есть моментальная возможность отмены удаления неограниченного количества удаленных записей. Когда у вас есть чекбоксы, иногда бывают ситуации, что человек либо машинально промахивается по записи, либо передумывает в последний момент удалять определенные записи, и ему приходится убирать галочки. Как быть с моментальным удалением в этом случае? Каждый раз спрашивать "Вы уверены?" нельзя.
3. Бывают случаи, когда во время выделения записей нужно отобразить какую-то статистику по выбранным. Например, это может быть какая-то сумма значений определенных столбцов записей или что-то еще. Во время моментального удаления такого не получится.
4. И еще один пункт, хотя он достаточно спорный, но все же. При моментальном удалении каждый раз отправляется запрос на сервер для изменения БД. При этом в БД могут существовать чрезвычайно "запутанные" связи между записями и таблицами. И каждый раз, когда вы будете удалять очередную запись, сервер должен будет обработать запрос, который может быть достаточно сложным. Если же веб-сервис содержит в себе функционал, который подразумевает частую работу с большим количеством записей и пользователей, то такие действия могут хорошо увеличить нагрузку на сервер.
Моментальное удаление удобно в некоторых узких моментах, да.
Но только тогда, когда:
1. Есть ТОЛЬКО удаление и нет других групповый операций. Если есть другие групповые операции, то убрать чекбокс нельзя. В этом случае как предлагаете быть с удалением?
2. Если есть моментальная возможность отмены удаления неограниченного количества удаленных записей. Когда у вас есть чекбоксы, иногда бывают ситуации, что человек либо машинально промахивается по записи, либо передумывает в последний момент удалять определенные записи, и ему приходится убирать галочки. Как быть с моментальным удалением в этом случае? Каждый раз спрашивать "Вы уверены?" нельзя.
3. Бывают случаи, когда во время выделения записей нужно отобразить какую-то статистику по выбранным. Например, это может быть какая-то сумма значений определенных столбцов записей или что-то еще. Во время моментального удаления такого не получится.
4. И еще один пункт, хотя он достаточно спорный, но все же. При моментальном удалении каждый раз отправляется запрос на сервер для изменения БД. При этом в БД могут существовать чрезвычайно "запутанные" связи между записями и таблицами. И каждый раз, когда вы будете удалять очередную запись, сервер должен будет обработать запрос, который может быть достаточно сложным. Если же веб-сервис содержит в себе функционал, который подразумевает частую работу с большим количеством записей и пользователей, то такие действия могут хорошо увеличить нагрузку на сервер.
Считаю каждый из предложенных Вами пунктов весьма спорным:
1. Примеры других операций над объектом, которые уместно реализовать предложенным мной способом: перемещение, копирование, скрывание, публикация.
Если последние два - это бинарные флаги и очевидно из проставить тут же, то первые могут потребовать более сложного решения (например попап со списком альтернатив "куда").
2. такая возможность (Undo) действительно может быть востребована. Но отсутствие ее не является прямым противопоказанием, ибо побуждает пользователя к более ответственному выбору. А "нажимаемость" и "попадучесть" по чекбоксу (не оснащенному текстовым лейблом) как раз меньше, по сравнению с текстовой ссылкой с соответствующей иконкой (покрашенной своим цветом), например.
3. Не получится что именно? Пересчитать значения после удаления? =) А статистика по выбранным элементам в списке , а не по всем элементам списка кажется мне весьма экзотическим случаем. Что бы это имело право на жизнь оно определенно должно быть основной фукциональностью списка (и такие задачи решаются как правило фильтром).
4. Пользователи не должны знать о внутренних проблемах реализации, пользователю нужно чтобы удобно и просто. Аргумент для ленивых или ограниченных в ресурсах разработчиков.
Также Вы утверждаете необходимость групповых операций именно для большого количества записей. Объясняю на все том же примере с удалением:
1. Есть список объектов который последовательно просматривается пользователем.
2. Объект в списке - это некая сущность, которая нужна (здесь), или не нужна. Неважно, не нужна здесь, нужна в другом месте, нужна в двух местах сразу.
3. Решение о том, нужна или не нужна запись принимается пользователем в тот момент, когда он на нее смотрит и читает то, что написано в строке презентирующей объект.
4. В том случае, если информации о принятии решения недостаточно пользователь тыкает по строке, попадает на страницу объекта и принимает решение там.
3. После того, как решение принято запись сразу удаляется не отходя от кассы.
При последовательном проходе по списку и применении операции удаления или других свойственных объекту операций список становится обработанным за одну итерацию.
Вы предлагаете:
Отдельный проход по списку с заранее принятым решением об удалении ненужных (если они есть) объектов. Решение о том нужен-не нужен конкретный объект принимается все равно только в контексте объекта (а не заранее). Решение фиксируется не действием (допустим необратимым), а галочкой (обратимо, но менее ответственно). Хинт: ответственный выбор экономит время.
получается что для каждого действия нужна отдельная итерация по списку, в результате каждой из которых получается список, требующий иногда дополнительной валидации от пользователя (то есть требует еще одной итерации внутри группы отмеченных).
Задачка-то алгоритмическая:
N - объекты
F - функции
P - общее кол-во действий: количество тыков + количество решений
мой вариант
для каждого объекта из N
[
__выбрать из F (решение P++)
__ткнуть в него (действие P++)
]
ваш вариант
для каждой функции из F
[
__для каждого объекта из N
__[
____если(нужна текущая функцию)(решение P++)
____[
______ткнуть в чекбокс (действие P++)
____]
__]
__если (есть сомнения) (решение P++)
__[
____вернуться в начало (действие P++)
____для каждого объекта из чекнутых
____[
______еще раз принять решение P++
______[
________ткнуть в чекбокс P++
______]
____]
__]
__нажать на кнопку групповой операции P++
]
наглядно?
1. Примеры других операций над объектом, которые уместно реализовать предложенным мной способом: перемещение, копирование, скрывание, публикация.
Если последние два - это бинарные флаги и очевидно из проставить тут же, то первые могут потребовать более сложного решения (например попап со списком альтернатив "куда").
2. такая возможность (Undo) действительно может быть востребована. Но отсутствие ее не является прямым противопоказанием, ибо побуждает пользователя к более ответственному выбору. А "нажимаемость" и "попадучесть" по чекбоксу (не оснащенному текстовым лейблом) как раз меньше, по сравнению с текстовой ссылкой с соответствующей иконкой (покрашенной своим цветом), например.
3. Не получится что именно? Пересчитать значения после удаления? =) А статистика по выбранным элементам в списке , а не по всем элементам списка кажется мне весьма экзотическим случаем. Что бы это имело право на жизнь оно определенно должно быть основной фукциональностью списка (и такие задачи решаются как правило фильтром).
4. Пользователи не должны знать о внутренних проблемах реализации, пользователю нужно чтобы удобно и просто. Аргумент для ленивых или ограниченных в ресурсах разработчиков.
Также Вы утверждаете необходимость групповых операций именно для большого количества записей. Объясняю на все том же примере с удалением:
1. Есть список объектов который последовательно просматривается пользователем.
2. Объект в списке - это некая сущность, которая нужна (здесь), или не нужна. Неважно, не нужна здесь, нужна в другом месте, нужна в двух местах сразу.
3. Решение о том, нужна или не нужна запись принимается пользователем в тот момент, когда он на нее смотрит и читает то, что написано в строке презентирующей объект.
4. В том случае, если информации о принятии решения недостаточно пользователь тыкает по строке, попадает на страницу объекта и принимает решение там.
3. После того, как решение принято запись сразу удаляется не отходя от кассы.
При последовательном проходе по списку и применении операции удаления или других свойственных объекту операций список становится обработанным за одну итерацию.
Вы предлагаете:
Отдельный проход по списку с заранее принятым решением об удалении ненужных (если они есть) объектов. Решение о том нужен-не нужен конкретный объект принимается все равно только в контексте объекта (а не заранее). Решение фиксируется не действием (допустим необратимым), а галочкой (обратимо, но менее ответственно). Хинт: ответственный выбор экономит время.
получается что для каждого действия нужна отдельная итерация по списку, в результате каждой из которых получается список, требующий иногда дополнительной валидации от пользователя (то есть требует еще одной итерации внутри группы отмеченных).
Задачка-то алгоритмическая:
N - объекты
F - функции
P - общее кол-во действий: количество тыков + количество решений
мой вариант
для каждого объекта из N
[
__выбрать из F (решение P++)
__ткнуть в него (действие P++)
]
ваш вариант
для каждой функции из F
[
__для каждого объекта из N
__[
____если(нужна текущая функцию)(решение P++)
____[
______ткнуть в чекбокс (действие P++)
____]
__]
__если (есть сомнения) (решение P++)
__[
____вернуться в начало (действие P++)
____для каждого объекта из чекнутых
____[
______еще раз принять решение P++
______[
________ткнуть в чекбокс P++
______]
____]
__]
__нажать на кнопку групповой операции P++
]
наглядно?
1. “первые могут потребовать более сложного решения (например попап со списком альтернатив "куда")”
Да, могут. И вот как раз в этом случае мгновенное действие (будем называть это так) не будет легко применимо – нельзя просить пользователя выбирать из контекстного меню дополнительную операцию для каждой записи. Или как это должно выглядеть? Ткнул копировать/выбрал куда, ткнул копировать/выбрал куда и т.п. Так что ли?
2. “отсутствие ее не является прямым противопоказанием, ибо побуждает пользователя к более ответственному выбору”
Это чистая философия.
Нельзя заставить пользователя быть в 10 раз ответственнее. Какой есть – такой есть. Со временем станет прилежнее, если характер позволит и ему это будет надо. Но и профессионалы иногда ошибаются. Поэтому отсутствие операции отмены как раз является прямым противопоказанием к применению мгновенного совершения операции. Почитайте Джефа Раскина (The Human Interface. New Directions for Designing Interactive Systems) ;).
И дело не в размере чекбоксов – их можно сделать в 3 раза больше!
Плюс, никто не мешает дополнительно сделать отметку группы записей давно известным способом: с помощью клавиш Shift/Ctrl (то, что в вебе не принято так делать – не аргумент. Можно вывести подсказку, например).
3. “Пересчитать значения после удаления?”
Опять невнимательно прочитали.
Почему после удаления? В процессе отметки элементов.
Например, подсчет общей стоимости чего-либо выбранных для копирования элементов… м-м, скажем, в списке подарков. Отправляю в благотворительный фонд подарки я, и у меня есть лимит суммы. И вот я отметил 10 подарков и вижу: ан нет, не уложился. Тогда я убираю отметку с самого дорогого подарка и взамен ставлю 2 подешевле.
4. Тут согласен. Сказал же, весьма спорный пункт ;)
”Также Вы утверждаете необходимость групповых операций именно для большого количества записей.”
И даже для небольшого при определенных условиях.
Иначе как реализовать ту же операцию копирования? Щелкать на каждую запись и выбирать, куда скопировать?
Например, в ОС как вы удаляете или копируете файлы, по одному или группой? Думаю, что группой. Хотя можно по одному, нажимая клавишу Del.
”Хинт: ответственный выбор экономит время.”
Не аргумент. Повторюсь, нельзя заставить пользователя стать вдруг ответственнее, чем он был, заходя на предыдущую веб-страницу. Какой уж есть.
Светофоры на улице стоят, чтобы обеспечить порядок; однако это не мешает некоторым не ждать зеленого света (весьма безответственно порой) и экономить свое время, успевая на тот же автобус ;)
”получается что для каждого действия нужна отдельная итерация по списку, в результате каждой из которых получается список, требующий иногда дополнительной валидации от пользователя”
Хорошо, представим ситуацию, когда над одной и той же группой элементов требуется произвести 2 последовательные независимые операции. Пусть это будет:
- пометить как ***
- переместить в ###
В вашем варианте я вижу это так:
- отмечаем первый элемент как ***, отмечаем второй элемент как *** и т.д.
- перемещаем первый элемент в ###, перемещаем второй элемент в ### и т.д.
В случае с групповыми операциями:
- отмечаем первый элемент, отмечаем второй элемент и т.д.
- выбираем 1 раз пометить как ***, выбираем 1 раз переместить в ###.
При возрастании количества элементов соотношение количества операций будет стремиться (раз уж все по уму :)) к 2:1. А если еще при перемещении в вашем случае надо будет выбирать “куда” для каждого элемента, то 3:1.
”Задачка-то алгоритмическая…[далее вырезано описание какое-то]“
Ха-ха! Чушь! =D
Да, могут. И вот как раз в этом случае мгновенное действие (будем называть это так) не будет легко применимо – нельзя просить пользователя выбирать из контекстного меню дополнительную операцию для каждой записи. Или как это должно выглядеть? Ткнул копировать/выбрал куда, ткнул копировать/выбрал куда и т.п. Так что ли?
2. “отсутствие ее не является прямым противопоказанием, ибо побуждает пользователя к более ответственному выбору”
Это чистая философия.
Нельзя заставить пользователя быть в 10 раз ответственнее. Какой есть – такой есть. Со временем станет прилежнее, если характер позволит и ему это будет надо. Но и профессионалы иногда ошибаются. Поэтому отсутствие операции отмены как раз является прямым противопоказанием к применению мгновенного совершения операции. Почитайте Джефа Раскина (The Human Interface. New Directions for Designing Interactive Systems) ;).
И дело не в размере чекбоксов – их можно сделать в 3 раза больше!
Плюс, никто не мешает дополнительно сделать отметку группы записей давно известным способом: с помощью клавиш Shift/Ctrl (то, что в вебе не принято так делать – не аргумент. Можно вывести подсказку, например).
3. “Пересчитать значения после удаления?”
Опять невнимательно прочитали.
Почему после удаления? В процессе отметки элементов.
Например, подсчет общей стоимости чего-либо выбранных для копирования элементов… м-м, скажем, в списке подарков. Отправляю в благотворительный фонд подарки я, и у меня есть лимит суммы. И вот я отметил 10 подарков и вижу: ан нет, не уложился. Тогда я убираю отметку с самого дорогого подарка и взамен ставлю 2 подешевле.
4. Тут согласен. Сказал же, весьма спорный пункт ;)
”Также Вы утверждаете необходимость групповых операций именно для большого количества записей.”
И даже для небольшого при определенных условиях.
Иначе как реализовать ту же операцию копирования? Щелкать на каждую запись и выбирать, куда скопировать?
Например, в ОС как вы удаляете или копируете файлы, по одному или группой? Думаю, что группой. Хотя можно по одному, нажимая клавишу Del.
”Хинт: ответственный выбор экономит время.”
Не аргумент. Повторюсь, нельзя заставить пользователя стать вдруг ответственнее, чем он был, заходя на предыдущую веб-страницу. Какой уж есть.
Светофоры на улице стоят, чтобы обеспечить порядок; однако это не мешает некоторым не ждать зеленого света (весьма безответственно порой) и экономить свое время, успевая на тот же автобус ;)
”получается что для каждого действия нужна отдельная итерация по списку, в результате каждой из которых получается список, требующий иногда дополнительной валидации от пользователя”
Хорошо, представим ситуацию, когда над одной и той же группой элементов требуется произвести 2 последовательные независимые операции. Пусть это будет:
- пометить как ***
- переместить в ###
В вашем варианте я вижу это так:
- отмечаем первый элемент как ***, отмечаем второй элемент как *** и т.д.
- перемещаем первый элемент в ###, перемещаем второй элемент в ### и т.д.
В случае с групповыми операциями:
- отмечаем первый элемент, отмечаем второй элемент и т.д.
- выбираем 1 раз пометить как ***, выбираем 1 раз переместить в ###.
При возрастании количества элементов соотношение количества операций будет стремиться (раз уж все по уму :)) к 2:1. А если еще при перемещении в вашем случае надо будет выбирать “куда” для каждого элемента, то 3:1.
”Задачка-то алгоритмическая…[далее вырезано описание какое-то]“
Ха-ха! Чушь! =D
И еще. Вы спрашиваете "Где экономия времени и дейсвий пользователя?"
Опять же вернемся к случаю, когда требуется удалить 50-70% записей.
В этом случае при наличии моментального удаления вам придется выделить как раз 50-70% записей. В случае же с чекбоксами обычно есть общий чекбокс, который отмечает чекбоксы записей. В этом случае вам нужно будет отметить 30%-50% записей.
Опять же вернемся к случаю, когда требуется удалить 50-70% записей.
В этом случае при наличии моментального удаления вам придется выделить как раз 50-70% записей. В случае же с чекбоксами обычно есть общий чекбокс, который отмечает чекбоксы записей. В этом случае вам нужно будет отметить 30%-50% записей.
В веб двойной клик может прокатить только для интранет-приложений. Где можно обучить ограниченное количество товарищей. А в местах общего пользования это будет неиспользуемый функционал.
А никто и не спорит :)
Я предложил это как _один из_ вариантов.
Хотя я могу не согласиться насчет "неиспользуемого функционала". Опять же, все зависит от нескольких факторов, например, целевой аудитории и от того, насколько вы готовы далеко пойти, предлагая людям нечто отличающееся от повсеместных не всегда удобных шаблонов. Но это уже другая тема имхо.
Я предложил это как _один из_ вариантов.
Хотя я могу не согласиться насчет "неиспользуемого функционала". Опять же, все зависит от нескольких факторов, например, целевой аудитории и от того, насколько вы готовы далеко пойти, предлагая людям нечто отличающееся от повсеместных не всегда удобных шаблонов. Но это уже другая тема имхо.
Ну шаблон одного клика в веб-среде настолько прижился, что ломать его будет очень сложно. И не понятно, нужно ли?
Насчет шаблонности интерфейсов разговор можно выстроить очень длинный :)
Читали Джефа Раскина (где-то недавно на Хабре была статья про него)?
Суть его высказываний в том, что не нужно бояться ломать стереотипы (про интерфейсы, в смысле), к которым привыкли люди, если то, что вы сделали, удобнее, чем то, к чему они привыкли. Человек должен обучиться и привыкнуть к машине, а не наоборот.
Точно не помню высказывание, но если интересно, найду и напишу.
Читали Джефа Раскина (где-то недавно на Хабре была статья про него)?
Суть его высказываний в том, что не нужно бояться ломать стереотипы (про интерфейсы, в смысле), к которым привыкли люди, если то, что вы сделали, удобнее, чем то, к чему они привыкли. Человек должен обучиться и привыкнуть к машине, а не наоборот.
Точно не помню высказывание, но если интересно, найду и напишу.
Я читал Раскина. Он пишет это про интерфейсы прошлого века. Сейчас те стереотипы уже успешно ломаются или сломаны. К примеру это интерфейсы, позволяющие возобновить прерванную работу, инкрементальный поиск и т.п.
О, я бы так не сказал (про прошлый век)! =)
Ну хорошо. Он писал о таких интерфейсах в прошлом веке. Правильная формулировка? :)
Нет, не совсем.
Он не рассматривал только конкретный подход к какому-то определенному куску интерфейса, а рассматривал с точки зрения, если хотите, психологии (хотя это слово мне не очень нравится тут, не знаю, как по-другому).
Я согласен с вами, что "ломать" стереотипы не просто, но это того стоит, имхо. Я не думаю, что чтобы привыкнуть к одинарному клику, пользователям надо много времени. Они же пользуются одинарным кликом в десктоп приложениях. Надо только дать понять, что такая возможность есть в данном интерфейсе.
Можно, например, написать подсказку, просигнализировать, сменив курсор на указатель в виде руки и т.п. :)
Он не рассматривал только конкретный подход к какому-то определенному куску интерфейса, а рассматривал с точки зрения, если хотите, психологии (хотя это слово мне не очень нравится тут, не знаю, как по-другому).
Я согласен с вами, что "ломать" стереотипы не просто, но это того стоит, имхо. Я не думаю, что чтобы привыкнуть к одинарному клику, пользователям надо много времени. Они же пользуются одинарным кликом в десктоп приложениях. Надо только дать понять, что такая возможность есть в данном интерфейсе.
Можно, например, написать подсказку, просигнализировать, сменив курсор на указатель в виде руки и т.п. :)
Лично меня в пхпмайадмине повторяющиеся кнопки не напрягают - избыточность интерфейса положительно сказывается на удобстве.
Откройте текстовый редактор из комплекта MS Office 2007, выделите блок текста и наведите мышь на выделенную область. Появится панелька. Попробуйте понять поведение, возможно это поможет придумать еще что-нибудь интересное.
А что мешает сделать контекстное меню на JavaScript?
Если речь идёт о меню по щелчку правой кнопки мыши, то мешает настоящее контесктное меню браузера.
Контекстное меню браузера можно предупредить. С помощью JS конечно-же. И оно перестает мешать.
В Битриксе например очень удобно сделано рядом с элементом располагается иконка, при нажатии на которую появляется вариант контекстного меню (аналогичное контекстное меню появляется также при нажатии на правую кнопку мышы в тех браузерах, которые поддерживают данную возможность)
Это нужно встревать в привычное всем поведения браузера по щёлчку правой кнопки мышки...
Это лишнее
Это лишнее
Контекстное меню требует от пользователя дополнительных действий — вызвать, посмотреть что можно сделать, и только потом уже делать…
Убирать иконки не всегда правильно, т.к. иногда они выполняют роль индикаторов.
любая идея связанная с упрощение вывода имеет право на жизнь, но тем не менее, зачастую руководствуясь принципом "убери_все_лишнее", получаем исходный вариант. велосипед на моей короткой памяти изобретается уже не первый раз.
в общем-то, все что появляется при наведении, не должно быть связано с основной информативностью. появляться может дополнительная информация и не более. далее надо идти по принципу индивидуальной настройки. кастомизация в любом интерфейсе - вот что спасет мир. =)
в общем-то, все что появляется при наведении, не должно быть связано с основной информативностью. появляться может дополнительная информация и не более. далее надо идти по принципу индивидуальной настройки. кастомизация в любом интерфейсе - вот что спасет мир. =)
Почему не сделать Ajax контекстное меню, которое будет всплывать при наведении на строчку? Библиотек куча Scriptaculous, Mootools, выбирай любую и реализуй!
Так, как сделано в phpMyAdmin - меньше всего требует времени для осмысления :) Хотя надо признать, что косяков в интерфейсе phpMyAdmin хватает, но уже других.
Не лишайте юзера чекбоксов для множественного выбора.
Не делайте появляющиеся внезапно элементы интерфейса, это некоторых бесит.
Не лишайте юзера чекбоксов для множественного выбора.
Не делайте появляющиеся внезапно элементы интерфейса, это некоторых бесит.
Согласен.
Кроме того, нужно помнить, что интерфейс должен быть стандартным.
Если юзер привык отмечать элементы для операций чекбоксами (как это обычно везде происходит), нужно дать ему такую возможность.
При этом можно сделать ненавязчивы альтернативный доступ к функции.
Кроме того, нужно помнить, что интерфейс должен быть стандартным.
Если юзер привык отмечать элементы для операций чекбоксами (как это обычно везде происходит), нужно дать ему такую возможность.
При этом можно сделать ненавязчивы альтернативный доступ к функции.
С одной стороны я тоже с вами согласен. Интернет, стандарты, пользователи привыкли... но если посмотреть с другой стороны, ну что мы эти чекбоксы будем тянуть за собой до конца интернета? Кликать на строку в таблице это по-моему довольно интуитивно и аналогично многим функциям в ОС, а чекбокс в таком контексте это всё-таки как-то неправильно и скорее уместнее в формах где решение для чего собвственно выбирать данный чекбокс принимается сразу. Так не стоит ли стараться искоренить эту дурную привычку пользователя в пользу интуитивности и простоты как использования так и имплементации.
Чекбоксы - это стандарт, и лучше него только список с выбором мышью, по ctrl и shift, когда группу нужных элементов тупо захватываешь на глазок и, если ошибся, поправляешь через ctrl. Как в виндовом проводнике. Но текущими средствами HTML этого добиться можно разве что через Ж. Проблема в ограниченности веб-интерфейса как такового. В данном случае я бы превратил значки удаления и других операций в ссылки вида [x] [+], расположенные непосредственно за названием элемента, и при этом оставил и чекбоксы.
Не забудьте о тех, кто плохо различает использованные Вашим дизигнером для сайта пятнадцать оттенков голубого и т.п.
Ну ладно. Преувеличивать не надо. Допустим на картинке только два оттенка да и то второй фон (тот что светлый) присваивается динамически. Но не в этом дело, это лишь пример имплементации и поменяв в CSS пару строк можно изменить всю гамму таблицы.
Я все же остаюсь при мнении, что выбранные строки следует помечать хотя бы треугольничком или галочкой, если Вы так не любите чекбоксы. Когда Вы выберете половину списка, ум за разум зайдет при наличии только цветового кодирования. Цвет же, который явно скажет "этот пункт выбран", придумать нельзя по определению ;)
Насчет ум за разум зайдёт это уже видимо тема для юзабилити теста на настояших "кроликах". У меня не заходит. На почте Яндекса например оставили чекбоксы. Я не могу определить чем конкретно они (студия Лебедева) руководствовались. Возможно какими-то техническими возможностями или боялись идти против стандартов, но у меня создаётся впечатление некой избыточности. Тоесть пользователь понимает что элемент выделен сразу после того как замечает изменение цвета и дальше вспомогательные средства просто мешают. Да и в различных ОС больше внимания уделяется именно цветовому кодированию.
Но раз уж речь пошла об отказе от цветового кодирования, то проще будет конечно использовать стандартный чекбокс.
Но раз уж речь пошла об отказе от цветового кодирования, то проще будет конечно использовать стандартный чекбокс.
Я не против цветового кодирования, сам его применяю где только могу, и легко различаю в списках порядка 7-8 разных цветов. Но на общеупотребительных сервисах я за минимализм и доступность, в том числе и для дальтоников и плохо видящих.
P.S. Насчет тыка и последующего изменения цвета - это неочевидно юзеру. Чекбокс - очевидно. А "ткни, чтобы выделить" - до этого додумываться надо ;)
P.S. Насчет тыка и последующего изменения цвета - это неочевидно юзеру. Чекбокс - очевидно. А "ткни, чтобы выделить" - до этого додумываться надо ;)
чекбоксы на почте яндекса, видимо, с почты гугла слизали
смайл: )
смайл: )
Если за перехват контекстного меню (удар по безопасности) нужно отрывать руки, то за "приглашение" удалять каждый элемент по отдельности - ЧЕТВЕРТОВАТЬ. Никто и никогда не может предвидеть всех потребностей пользователя. Маркетологи "видят" рынок подобно человеку с фонариком ночью в туманном лесу, и это естественно. Вместо того, чтобы пытаться предугадать все потребности пользователя, нужно не мешать пользователю использовать то, что у него есть, так, как ему хочется. Проблема-то решается обыкновенным юзерским скриптом Greasemonkey, но до этого додумается один из тысячи, а 999 тупо покинут негостеприимный ресурс и будут правы. Хронофаги недостойны расстрела - им только йад и об стену.
Чтобы заставить дизайнера думать, надо отобрать у него контекстное меню. Видимо поэтому, те, которые на Маках задумываются чаще.
интересная статья.
Sign up to leave a comment.
Повторяющиеся кнопки в таблицах