Веб-дисплеи: пейджинг и длинные таблицы

Question

Кажется, что тенденция в веб-дизайне заключается в предоставлении постраничного вывода, где длинные таблицы отображаются по странице за раз. Моим клиентам это не нравится, и они просят, чтобы веб-сайты, которые я для них разрабатывал, отображали все записи в длинных таблицах. Похоже, что аргументы для подкачки страниц в основном основаны на снижении производительности при отображении длинных таблиц, и это не так важно для корпоративной интрасети с высокой пропускной способностью. Аргументы против разбиения на страницы включают возможность печати всей таблицы, поиск строк по всей таблице, выбор произвольных диапазонов из всей таблицы для копирования и т. Д. Я указал, что эти функции можно легко добавить в веб-дизайн с постраничной передачей (например кнопка печати, которая печатает всю таблицу, или кнопка, которая создает CSV-файл таблицы), но постраничный вывод по-прежнему кажется им неудобным. Наш типичный стол составляет от 100 до 600 наименований. Очевидно, что таблицы, которые будут значительно больше, вероятно, придется разбивать на страницы.

Вопросы:

1. Какой у вас опыт личных или клиентских предпочтений для постраничного и полного вывода в длинных таблицах?
2. Инструменты веб-дизайна, похоже, продвигают парадигму подкачки. Они не на связи или мои клиенты необычные?
3. Если вы думаете: «Это зависит от длины стола», какой порог вы бы использовали?

Answer 1

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

2. Я думаю, что ваши клиенты очень обычные и общительные.

3. Порог будет о времени загрузки страницы. Когда сервер не может создать полные списки достаточно быстро, или когда списки становятся такими длинными, что браузер замедляется. (Последнее может произойти для довольно коротких списков, если у вас есть CSS-элементы, не связанные с тегами, и браузер IE.)

Дайте пользователям мощную функцию поиска, и они сами сузят свои списки страниц.

Answer 2

Укажите длину страницы по умолчанию и настраиваемый параметр (например, в строке запроса для программного использования и / или форму на веб-странице для интерактивного использования), чтобы контролировать количество записей на странице.

Гибкость пользователя хороша. Texas Instruments имеет инструмент параметрического поиска для инженеров-электриков, чтобы найти интегральные схемы, которые соответствуют определенным техническим характеристикам, и они включают в себя ссылку «показать все» на веб-странице и «загрузить все» в виде файла .csv. Это хорошая модель, спасибо TI. То же самое к Flickr; их API позволяет контролировать (в значительной степени), сколько результатов будет отображаться при вызове веб-службы.

Лично я НЕНАВИЖУ веб-сайты, которые по умолчанию имеют 10 списков на странице, но не могут увеличить их. Чтобы просмотреть их, нужно НАВСЕГДА, и я готов подождать дольше, если смогу получить все вещи сразу.

Если это интерактивная веб-страница, я бы подумал о том, чтобы перейти на решение AJAX, которое загружает 100 за раз, так что есть индикация прогресса (и пользователь может остановить его, если есть 20000 результатов).

Я согласен с PEZ, все дело в отзывчивости.

Answer 3

Почему бы просто не настроить пользовательский параметр? Похоже, вы планируете по существу реализовать оба в любом случае.

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

Answer 4

Я очень хорошо понимаю вашу ситуацию. Я был в похожей ситуации. Я перевёл бизнес-процесс из управления человеком в автоматизированный. Первоначально это было сделано с использованием таблиц Excel. Заинтересованные стороны для моего программного обеспечения были в возрасте 55 лет и старше, им не нравилось что-либо ajaxy или какой-либо шаблон пользовательского интерфейса, о котором вы говорите. В таких случаях логика получения данных может быть оптимизирована. Любая таблица, которая касается отметки в 1 КБ или содержит такие элементы, как пятна изображения или тому подобное, должна показываться по частям с точки зрения производительности.

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

Счастливого кодирования!

Answer 5

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

Answer 6

Лучшее решение: не предоставлять списки, содержащие более 100 наименований.

Обычно ваш пользователь не хочет читать более 100 или даже 600 предметов. Им просто все равно. Они ищут одного (или, возможно, несколько). Убедитесь, что у них есть способ добраться до этих предметов без визуального поиска в списке.

А если ваш клиент настаивает на отображении всех элементов, предоставьте подкачку с настраиваемым размером страницы и, если он этого захочет, введите "100000 элементов на страницу".