Выношу из одного частного обсуждения вот такую идею способа представления фильтра:



Здесь изображено как меняется дерево при раскрытии плюсиков.

Ну а отдельные строчки можно уже редактировать in-place либо открывать для них окно редактирования...

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

N>Ну а отдельные строчки можно уже редактировать in-place либо открывать для них окно редактирования...

не сложновато для пользователей?

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

N>Выношу из одного частного обсуждения вот такую идею способа представления фильтра:
N>http://www.ljplus.ru/img/n/z/nzeemin/FilterEditing.png
N>Здесь изображено как меняется дерево при раскрытии плюсиков.

А не пугает (пользователя) то, что при раскрытии ноды что-то необъяснимым образом меняется и визуально становится практически невозможно определить, где же было выделение до раскрытия?

N>Ну а отдельные строчки можно уже редактировать in-place либо открывать для них окно редактирования...

Вообще, идея нравится.

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

_FR>А не пугает (пользователя) то, что при раскрытии ноды что-то необъяснимым образом меняется и визуально становится практически невозможно определить, где же было выделение до раскрытия?

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

Как сегодня сказал один мой коллега — "еще не разу видел фильтра, которым бы было не противно пользоваться". Полностью с ним согласен...

N>Как сегодня сказал один мой коллега — "еще не разу видел фильтра, которым бы было не противно пользоваться". Полностью с ним согласен...

Если простенький то мне вот такой нравится:

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

А>Если простенький то мне вот такой нравится:
А>

Это действительно простой случай, объединение операций только через И или только через ИЛИ.
Речь же изначально идет о фильтрах с более сложной структурой — с ними и возникают проблемы.

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

_FR>>А не пугает (пользователя) то, что при раскрытии ноды что-то необъяснимым образом меняется и визуально становится практически невозможно определить, где же было выделение до раскрытия?

N>Если мне не изменяет память, обычно при раскрытии плюсика выделение никуда не девается.

А как ты это узнаешь\докажешь? Что общего будет у узла, на котором было выделение до раскрытия и у узла, на котором окажется выделение после раскрытия?

N>Ну а то, что меняется — в первый раз может испугать, это да. Но повторное нажатие на плюсик покажет ему, что все не так плохо

Было бы здорово кроме текста идентифицировать узел (для пользователя) ещё каким-либо образом, не меняющимся при раскрытии\закрытии. Например, таким параметром может быть цвет (текста\фона\иконки\… — отдельный вопрос).

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

N>Выношу из одного частного обсуждения вот такую идею способа представления фильтра:

N>

N>Здесь изображено как меняется дерево при раскрытии плюсиков.

N>Ну а отдельные строчки можно уже редактировать in-place либо открывать для них окно редактирования...

Лично мне по душе вариант со списком. Т.е. каждая строка, это условие, а переходы между ними это логические операции. Проще получается.

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

N>Выношу из одного частного обсуждения вот такую идею способа представления фильтра:

N>

N>Здесь изображено как меняется дерево при раскрытии плюсиков.

N>Ну а отдельные строчки можно уже редактировать in-place либо открывать для них окно редактирования...

В общем и целом интересно. Несколько дополнительных мыслей:

1) Слово LIKE весьма специфично и, как показывает практика, пользователи не всегда понимают его суть, особенно если возникает необходимость сделать фильтр типа LIKE '%Иванов' и тому подобные. Всё-таки лучше было бы, ИМХО, найти другое словоюрешение для таких случаев.

2) Предполагаю, что для фильтров, содержащих N>5 условий восприятие будет уже достаточно сложно.

3) Очень неплохо было бы ввести цветовое выделение типа такого:

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

4) Самое, наверное, важное замечание — это возможное непонимание пользователем "стековой нотации" записи фильтра. Поясняю. Нормальному человеку (который никогда не писал синтаксических анализаторов к компилятору) куда как проще воспринимать логику последовательно, а не как стек. В текущем примере представлена следующая логика раскрытия:

ИЛИ
"Аргумент 1"
"Аргумент 2"

а люди всё-таки воспринимают следующую логику записи:
"Аргумент 1" ИЛИ "Аргумент 2"

Поэтому рядом с плюсом (т.е. собственно название узла) нужно ставить Аргумент, а не действие, а действие. Например, что-то вроде этого:

(-) Заказчик СОДЕРЖИТ "Иванов"
    И
        (-) Сумма_заказа > 10000
            ИЛИ
            Приоритет > 3

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

S>1) Слово LIKE весьма специфично и, как показывает практика, пользователи не всегда понимают его суть, особенно если возникает необходимость сделать фильтр типа LIKE '%Иванов' и тому подобные. Всё-таки лучше было бы, ИМХО, найти другое словоюрешение для таких случаев.

Предлагаю заменить на ТИПА

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

N>Выношу из одного частного обсуждения вот такую идею способа представления фильтра:

Очень удобно работает решение от DevExpress. Не хватает мелких доработок. Зато просто и наглядно.