Имеется GUI-приложение, в котором пользователь может работать со списком некоторых объектов (неважно каких именно).
С ними пользователь может делать некоторые действия, причем как с одиночным объектом, так и с группой объектов.
Список объектов получается из некоторого источника данных и может обновляться по команде пользователя.
Проблема в том, что список может быть очень большим и его обновление может занимать долгое время.
Как, по-вашему, это приложение должно вести себя при обновлении списка, чтобы пользователю было удобно работать?

Вариант 1.
При обновлении списка показываем песочные часы, окно с прогрессбаром и т.п. — в общем, ждем-с, при этом операции с объектами
списка заблокированы.
Чем плохо — пока список обновляется, пользователь ничего полезного сделать не может

Вариант 2.
Обновляем список по частям: подгрузили очередной кусок — добавили в список — отрисовали, и т.д., при этом пользователь может выполнять
операции с объектами из уже подгруженной части списка
Чем плохо — если пользователь, например, нажмет Ctrl+A, непонятно как быть:
2а) Выделить уже подгруженную часть списка — плохо тем, что пользователь, будучи уверенным, что выделил все, выполнит
какую-нибудь групповую опреацию и получит совсем не то что хотел
2б) Ожидать полной загрузки списка — а если пользователь задолбается ждать и захочет отменить "выделить все" — что тогда?

Вариант 3.
То же, что и в.2, но до полного обновления списка разрешаем пользователю только операции с одиночными объектами, а групповые операции блокируем
Чем плохо — непривычно для неподготовленного пользователя: почему одни операции работают, а другие нет?

Может быть, есть еще какие-нибудь разумные варианты?

P.S. Возможность делать групповые операции с полным списком объектов или с большим его подмножеством — принципиальна, так
что вариант "Отказаться от Ctrl+A" не годится

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

А>Имеется GUI-приложение, в котором пользователь может работать со списком некоторых объектов (неважно каких именно).
А>С ними пользователь может делать некоторые действия, причем как с одиночным объектом, так и с группой объектов.
А>Список объектов получается из некоторого источника данных и может обновляться по команде пользователя.
А>Проблема в том, что список может быть очень большим и его обновление может занимать долгое время.
А>Как, по-вашему, это приложение должно вести себя при обновлении списка, чтобы пользователю было удобно работать?

А>Вариант 1.
А> При обновлении списка показываем песочные часы, окно с прогрессбаром и т.п. — в общем, ждем-с, при этом операции с объектами
А>списка заблокированы.
А> Чем плохо — пока список обновляется, пользователь ничего полезного сделать не может

А>Вариант 2.
А> Обновляем список по частям: подгрузили очередной кусок — добавили в список — отрисовали, и т.д., при этом пользователь может выполнять
А>операции с объектами из уже подгруженной части списка
А> Чем плохо — если пользователь, например, нажмет Ctrl+A, непонятно как быть:
А> 2а) Выделить уже подгруженную часть списка — плохо тем, что пользователь, будучи уверенным, что выделил все, выполнит
А>какую-нибудь групповую опреацию и получит совсем не то что хотел
А> 2б) Ожидать полной загрузки списка — а если пользователь задолбается ждать и захочет отменить "выделить все" — что тогда?

А>Вариант 3.
А> То же, что и в.2, но до полного обновления списка разрешаем пользователю только операции с одиночными объектами, а групповые операции блокируем
А> Чем плохо — непривычно для неподготовленного пользователя: почему одни операции работают, а другие нет?

А>Может быть, есть еще какие-нибудь разумные варианты?

А>P.S. Возможность делать групповые операции с полным списком объектов или с большим его подмножеством — принципиальна, так
А>что вариант "Отказаться от Ctrl+A" не годится

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

А>Проблема в том, что список может быть очень большим и его обновление может занимать долгое время.

Вот эту проблему IMHO и нужно решать.

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

А>Имеется GUI-приложение, в котором пользователь может работать со списком некоторых объектов (неважно каких именно).
А>С ними пользователь может делать некоторые действия, причем как с одиночным объектом, так и с группой объектов.
А>Список объектов получается из некоторого источника данных и может обновляться по команде пользователя.
А>Проблема в том, что список может быть очень большим и его обновление может занимать долгое время.
А>Как, по-вашему, это приложение должно вести себя при обновлении списка, чтобы пользователю было удобно работать?

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

Если пользователь нажал Ctrl+A, переходим в модель хранения списка исключений. Изначально исключений нет, выделены все объекты. По мере получения элементов списка отрисовываем их выделенными. Даём пользователю снимать выделение с уже загруженных элементов. Даём действовать над выделенной группой — если возможно, транслируем это в команду серверу «действовать над всеми элементами, кроме», типа «update … where id not in (…)». Если сервер так не умеет, ставим себе в очередь задачу, подписываем её на события изменения списка, передаём список исключений, и пусть в фоне выполняет работу.

Если в режиме «всё, кроме» юзер тыкает какой-нибудь одиночный элемент или ещё как-то сбрасывает выделение, возвращаемся в режим «это, это и это».


Вариант интерфейса: пока список не догружен, показываем в конце метаэлемент «More…» (если возможно, показываем, сколько именно more). Даём его выделять. Все новопоступившие элементы получают статус выделения с этого метаэлемента. Поведение — такое же, как описано выше.

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

А>Имеется GUI-приложение, в котором пользователь может работать со списком некоторых объектов (неважно каких именно).
..
А>Может быть, есть еще какие-нибудь разумные варианты?

1. Не показывать пользователю большие списки. Сделай фильтр и т.п. зачем пользователю выбирать десяток вариантов из 10000?
Самое оно 8-50 элементов и нефиг больше.

2. И потом если пользователь нажал выделить всё что мешает вновь подгруженные отмечать как выделенные?

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

Вариант 4.

"Выбрано всё" это состояние не отдельных элементов, а всего списка.

Т.е. если в момент догрузки пользователь не выдержал и нажал кнопку "удалить" например (до завершения загрузки) то
это равносильно нажатию на кнопку "удалить все".

Можно сделать selection на серверной стороне. Даже если я сказал Ctrl+A, потом DEL, у меня удалиться все, даже если список еще не загрузился на клиент. Еще можно не грузить список на клиент вообще целиком. Грузить только окно, которое показывается.

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

Само собой показывать огромное количество записей — плохое решение. Как минимум надо выводить предупреждение.

Я бы сделал список виртуальным (т.е. читал данные только при необходимости) и хранил выбранные диапазоны в отдельной модели. При отображении записи подсветка select/non-selected управлялась бы из этой модели. Правда не все контролы позволяют такую гибкость, увы.

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

K>Можно сделать selection на серверной стороне. Даже если я сказал Ctrl+A, потом DEL, у меня удалиться все, даже если список еще не загрузился на клиент. Еще можно не грузить список на клиент вообще целиком. Грузить только окно, которое показывается.

Я вообще-то имел ввиду что при выделении "Ctrl+A" можно прдолжать отменять выделение элементов и их групп. Т.е.
список вот такого вида:

list active_items;
bool invert_selection;

т.е. список элементов которые пользователь потыркал и флаг инвертирования

invert_selection() { invert_selection^=1; }
tougle_item(item)  { active_items[item].marked^=1; }
select_all()       { active_items.clear(); invert_selection=+1; }
select_none()      { active_items.clear(); invert_selection= 0; }

Сделайте эти два списка не сервере. Скачивайте на клиента только тот кусок, который нужно показать.

Мне кажется, что такие проблемы возникают, когда UI слишком привязан к данным/моделям. Но я вашей ситуации конечно не знаю, это так, умничаю.

Еще мне кажется, что решить эту проблему трудно из-за недостатка предоставленной информации. Во-первых, непонятно, насколько сами данные, с кот. работает программа, ценны, какова цена возможной ошибки оператора? Это может быть комп. игра, где юзер в результате ошибки просто чертыхнется и забудет (или даже не заметит), а может быть и совсем не игра. Во 2-х, как вообще выглядит UI, т.е. общий "уровень юзабилити", все то, что в сумме определит вероятность ошибки? Как конкретно выглядит список? Надо ли оператору вчитываться в каждый элемент списка (например, не содержат ли эл-ты какие-то безумные номенклатурные названия, в каждое из которых надо вглядываться, и от которых может "рябить в глазах", или это такой список, в котором можно отловить нужное, просматривая его "по диагонали")? Важно и кто юзер. Какова предполагаемая скорость, интенсивность его работы с этим списком? Список полностью обновляется за минуту, за час? Не описано также, каково разнообразие и сложность действий оператора с выбираемыми эл-тами. Нет "мелочей". Не исключено, что что-то посоветовать здесь можно, только посмотрев действующий прототип.

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

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

Как вариант, показывать в конце списка элемент "остальные N элементов" и дать пользователю возможность "раскрыть" его. Полностью решается проблема предсказуемости.