HCI: заставить пользователя ждать через все сразу или амортизировать?

Question

Я пишу приложение silverlight, которое запрашивает веб-сервис для заполнения древовидного элемента управления. Каждый элемент будет иметь как минимум 2 уровня дочерних, так что-то вроде этого:

a
+-b
  +-c
d
+-g
  +-h
e
+-i
  +-j
f
+-k
  +-l

API веб-службы таков, что я могу получить только один уровень дочерних узлов за раз, поэтому при первой поездке я могу получить a, d, e, f. Чтобы получить b, g, i, k, мне нужно совершить 4 поездки. Точно так же я должен сделать еще 4 поездки, чтобы получить c, h, j, l. (Сервис действительно позволяет мне получить все узлы за одну поездку, но он не дает мне отношения родитель-потомок вместе с ним: - ()

У меня такой вопрос: я должен заставить пользователя ждать некоторое время вперед, пока я получаю все узлы для представления дерева, или я должен просто получить несколько верхних узлов и получить другие узлы по требованию, или в фоновом режиме? Кроме того, узлы могут изменяться асинхронно, поэтому, если я получу все узлы заранее, мне понадобится кнопка «обновить» для просмотра дерева, и если я сделаю это по требованию, мне потребуется стратегия кэширования.

Что лучше для пользователя?

Answer 1

Компромисс, когда вы загружаете первый уровень заранее, а затем загружаете оставшиеся элементы в фоновом режиме, перезаписываемые по требованию по мере необходимости. Если вы сначала загружаете узлы по ширине (например, a, d, e, f, затем b, g, i, k), а не по глубине (например, a, d, e, f, а затем b, c), вы можете перенаправить загрузку в сфокусироваться на самом последнем расширенном узле.

Answer 2

Краткий ответ - заставить пользователя ждать как можно меньше. Они проклянут ваше имя, если им придется ждать 10-20 секунд при загрузке приложения, но не заметят 0,1-0,2 секунды для расширения узла дерева.

У меня есть приложение с похожей структурой. Я не могу загрузить заранее, потому что это будет эффективно загружать всю базу данных. Вот моя стратегия:

• Управление деревом начинается с 1 уровня, развернутого ниже корня.
• Каждый нерасширенный узел имеет фиктивный дочерний узел, чтобы значок расширения [+] отображал
• Когда узел раскрывается, он запускает событие, которое перехватывается приложением. Если единственный дочерний узел является фиктивным, то фиктивная папка удаляется, а дочерние узлы загружаются из базы данных.
• Изменения в данных не отражаются автоматически видимыми узлами, однако в контекстном меню для дерева есть пункт Обновить, который можно использовать для обновления узла.

Я рассмотрел возможность показа обновлений асинхронно, но старался избегать этого, потому что в дереве могут отображаться большие объемы данных, и я опасаюсь загрузки БД, если проверяю их все на наличие изменений.

Приложение - WinForms, написанное на C # с использованием .NET 2.0.

Answer 3

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

Но, я полагаю, это зависит от нескольких особенностей вашего приложения / данных:

• Насколько динамичны данные? Обновляется ли он чаще, чем скорость, с которой пользователь исследует узлы? Если это произойдет, вам придется читать данные, когда пользователь исследует их, в противном случае вам, вероятно, удастся избежать только их обновления время от времени и проверяя самые свежие данные перед выполнением важных операций.
• Какую часть данных пользователь будет изучать при обычном использовании? Если они постоянно исследуют все дерево, то важно загрузить все дерево. С другой стороны, если большинство пользователей обычно расширяют только небольшую часть дерева, то, возможно, загрузка по требованию лучше, поэтому вы не тратите свое время на загрузку данных, которые они никогда не увидят.
• Насколько это влияет на производительность? Действительно ли загрузка всех данных занимает много времени? Если данных не слишком много, может быть, все это может быть загружено за считанные секунды, и в этом случае объем работы по реализации Оптимизация не будет иметь существенного значения для конечного пользователя и, в свою очередь, не обеспечит хорошую отдачу от инвестиций.

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