Оно реально увлекательно, но для прикладных задач пока трудно применимо. Я пытался использовать RDF (в связке с XBL и SVG) для хранения, фильтрации и графического представления большого количества связанной информации (более 100 000 фактов) средствами FF но некоторые специфические проблемы производительности и инструментария вынудили дождаться mozStorage (встроенный в браузер SQLite) и продолжать реализацию на более низком уровне. Полагаю, что продакшен приложения на основе RDF вопрос будущего, а построение больших семантических систем чрезмерно ресурсоемко. Хотя безусловно интересно.
"сотни тысяч долларов упущенной прибыли" — вот он, звериный оскал капитализма. =)
А по сути ситуацию может исправить только наличие мозга и временных ресурсов у разработчика сайта, поскольку ни одна серебрянная пуля (стандарты, стайлгайды, фреймворки) не решают проблемы связанные с отсутствием информационной архитектуры
Считаю каждый из предложенных Вами пунктов весьма спорным:
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++
]
наглядно?
Групповая операция для удаления нужна в первую очередь для экономии трафика и времени на перезагрузку страницы. В данном случае этот аспект исключается применением аякса.
Про другие групповые операции нужно думать отдельно. Я привел пример операции удаления как иллюстрирующий мою мысль. Мысль об отсутствии необходимости отмечать прежде чем удалять. Приведите реальный пример групповой операции и можно подумать, стоит ли ее заменить индивидуальным действием, или не стоит.
Я стараюсь рассматривать конкретные случаи, так как для них проще выработать решение чем для абстрактной ситуации. Тем более не хочу разговаривать об абстракциях, что у нас с вами появляются заведомо разные контексты и мы говорим о разных вещах. Ассиметричный дуализм языкового знака, проще говоря =)