Веб-дисплеи: Подкачка страниц по сравнению с длинными таблицами
Оценка модели всегда сводится к разделению имеющихся данных на три набора: обучение , проверка и тест . Вы тренируетесь на данных обучения и оцениваете свою модель на данных валидации. Когда ваша модель готова к прайм-тайму, вы в последний раз тестируете ее на тестовых данных.
Теперь, в реальной проблеме, мы получаем обратную связь или результат или разработанную модель только после того, как она используется пользователем или взаимодействует с данными, которые она никогда не видела раньше. И это настоящий тест .
Таким образом, во время разработки, мы полагаемся только на некоторые процедуры. Разделение ваших данных на обучающие, проверочные и тестовые наборы может показаться простым, но есть несколько продвинутых способов сделать это, которые могут пригодиться, когда доступно мало данных. Три классических рецепта оценки: простая проверка удержания , проверка Кфолда и повторная проверка K-кратности с перемешиванием.
6 ответов
Я люблю длинные списки на одну страницу. Одна из нескольких причин I видит для разбитого на страницы списка, те, Вы указываете о производительности.
Я думаю, что Ваши клиенты очень обычны и в касании.
Порог был бы во времена загрузки страницы. Когда сервер не может произвести полные списки достаточно быстро или когда списки становятся такими длинными, который замедляет браузер. (Последний может произойти для довольно коротких списков, если у Вас есть материал парения нетега в Вашем CSS, и браузером является IE.)
Дайте пользователям мощную поисковую функцию, и они сузят свои списки страницы сами.
Почему не просто имеют его быть пользователем настраиваемая опция. Это кажется, что Вы планируете по существу реализовать обоих так или иначе.
Чтобы быть честным, я думаю, что, неважно, который Вы выбираете, кто-то будет жаловаться. По крайней мере, с ним являющийся пользователем, настраивающимся, у Вас есть способность отложить его на пользователе.
Обеспечьте длину страницы по умолчанию и конфигурируемый параметр (например, в строке запроса для программного использования и/или форме на веб-странице для интерактивного использования) для управления, сколько списков находится на странице.
Пользовательская гибкость хороша. Texas Instruments имеет параметрическое средство поиска для инженеров-электриков для нахождения ICS, которые встречают определенные технические характеристики, и они включают ссылку и чтобы "показать, что все" на веб-странице и "загружают все" как .csv файл. Это - хорошая модель, благодарность TI. Так же к flickr; их API позволяет Вам управлять (в большой степени), сколько результатов обнаруживается на вызове веб-сервиса.
Я лично НЕНАВИЖУ веб-сайты что значение по умолчанию к 10 спискам на страницу без способа увеличить его. Это берет НАВСЕГДА для просмотра их, и я готов ожидать дольше, если я могу получить весь материал сразу.
Если бы это - интерактивная веб-страница, я рассмотрел бы движение к решению для Ajax, которое загружает 100 за один раз, таким образом, существует признак прогресса (и пользователь может остановить его, если существует 20 000 результатов).
Я соглашаюсь с PEZ, это - все о скорости отклика.
Одна из основополагающих книг по веб-дизайну (извините, я забываю, какой), раньше говорил для не рассчитывания на пользователей, прокручивающих вниз, потому что большинство из них не знает, как или не может быть побеспокоен. Я думаю, что более свежее обновление говорит, что, в то время как, верно для широкой публики, определенные секторы большего количества технических пользователей, как могут ожидать, прокрутят вниз, и можно сделать страницы, которые требуют прокрутки ЭКВИВАЛЕНТНОСТИ (если и только эквивалентность), Вы знаете, что Ваши пользователи могут обработать его.
Лучшее решение: не предоставляйте спискам больше чем 100 объектов.
Обычно Ваш пользователь не хочет читать больше чем 100 или даже 600 объектов. Они просто не заботятся. Они ищут один (или возможно некоторые). Удостоверьтесь, что существует способ для них добраться до тех объектов без visual-grep-ing через список.
И если Ваш клиент настаивает на том, чтобы отображать все объекты, то предоставьте подкачке страниц настраиваемый размер страницы и позвольте ему ввести "100 000 объектов на страницу", если он хочет.
Я могу понять Вашу ситуацию чрезвычайно хорошо. Я был в аналогичной ситуации. Я переместил бизнес-рабочий процесс от того, чтобы быть человеком, управляемым к автоматизированному. Первоначально это было выполнено с помощью электронных таблиц Excel. Заинтересованные стороны для моего программного обеспечения были в возрастной группе 55 +, им ничто не нравится ajaxy или любой из шаблонов UI, о которых Вы говорите. Это такая логика извлечения данных случаев может быть оптимизировано. Любую таблицу, которая касается метки 1K или имеет объект как блобы изображения или подобные вещи, нужно показать в частях с точки зрения производительности.
- долгие выводы медленный рендеринг и будут пиявкой производительности
- Клиенты не хотят к изменениям большинство раз, и клиент всегда прав, если Вы не можете убедить их.
- Я выдвинул свой threshhold, но он также зависит от содержания строк.
Счастливое кодирование!