Веб-дисплеи: пейджинг против длинных таблиц
Кажется, что тенденция веб-дизайна состоит в том, чтобы предоставлять постраничный вывод, когда длинные таблицы отображаются постранично. Моим клиентам это не нравится, и они попросили, чтобы веб-сайты, которые я для них разрабатывала, отображали все записи в виде длинных таблиц. Аргументы в пользу разбиения на страницы, по-видимому, в основном основаны на снижении производительности при отображении длинных таблиц, и это не вызывает беспокойства в корпоративной интрасети с высокой пропускной способностью. Аргументы против разбиения на страницы включают возможность распечатать всю таблицу, выполнять строковый поиск по всей таблице, выбирать произвольные диапазоны из всей таблицы для копирования и т. д. Я указал, что эти функции могут быть легко добавлены в страничный веб-дизайн (например, кнопку печати, которая печатает всю таблицу, или кнопку, которая создает CSV-файл таблицы), но постраничный вывод по-прежнему кажется им неудобным. Наша типичная таблица составляет от 100 до 600 элементов. Очевидно, что таблицы, которые были бы значительно больше, вероятно, должны были бы быть выгружены.
Вопросов:
- Каков ваш опыт работы с личными предпочтениями или предпочтениями клиентов в отношении постраничного и полного вывода в длинных таблицах?
- Инструменты веб-дизайна, похоже, продвигают парадигму разбиения на страницы. Они вне связи или мои клиенты необычны?
- Если вы думаете: «Это зависит от длины стола», какой порог вы бы использовали?
Ответы 6
Почему бы просто не сделать это параметром, настраиваемым пользователем. Похоже, вы в любом случае планируете реализовать и то, и другое.
Если честно, я думаю, что что бы вы ни выбрали, кто-то будет жаловаться. По крайней мере, поскольку он настраивается пользователем, у вас есть возможность вернуть его пользователю.
Я могу понять теорию, но как опытный пользователь я ненавижу приложение, когда оно применяется ко мне. :) Я полагаю, что ответ, который я предоставил, исходит из точки зрения меня как пользователя.
Что касается конкретно этого сообщения, я думаю, это будет зависеть от данных. В частности, сколько времени нужно, чтобы составить большой список. В качестве примера я всегда устанавливаю для Google значение 100 на страницу, и я бы хотел, чтобы он был больше, но это практично только потому, что текущая скорость интернета позволяет отображать его достаточно быстро.
Что ж, когда разработчики делают неправильный выбор (например, на iPhone, где они думают, что автоматический наклон страницы при наклоне устройства - хорошая идея), тогда это отстой. Но когда выбор хороший, вы его просто не замечаете.
Из сообщения «Да, ты мог бы сделать плохой звонок. Но что с того. Если ты это сделаешь, люди будут жаловаться и рассказывать тебе об этом. Как всегда, ты можешь приспособиться. Реальность - это возможность меняться на лету. "
проблема в том, что это такие вещи, которые, как бы вы ни настраивали, в этом случае все равно будут жаловаться.
Я сомневаюсь в этом. Я не знаю пользователей, которые хотели бы пейджинг, когда у них есть все на одной тарелке. Особенно, если вы дадите им поле поиска, которое может сузить список до нескольких элементов, которые им интересны.
Тогда почему, как вы думаете, пейджинг так распространен? Я должен думать, что если бы все хотели этого одинаково, то другой способ не был бы таким популярным.
И если придерживаться примера с Google, если бы я все еще застрял на коммутируемом соединении 56k (и не обманываете себя многие люди), то я бы, конечно, не делал 100 на страницу. Это правда, что вы можете определять скорость и динамически регулировать, но я думаю, что это добавит ненужной сложности.
Однако я хочу прояснить, что ни одно из этих обсуждений никоим образом не доказывает, что пользовательская конфигурация является лучшей. Просто я выражаю свое личное мнение.
Думаю, мы с вами согласны. Единственная причина для пейджинга, которую я могу принять, - это проблемы со временем загрузки страницы. Я работаю над системой, в которой IE заставляет нас выполнять разбиение на страницы из-за неудачной реализации наведения курсора на не-теги. В интрасети с мощными серверами. Перейти полные списки!
Лучшее решение: не предоставляйте списки, содержащие более 100 элементов.
Обычно ваш пользователь не хочет читать больше 100 или даже 600 статей. Им просто все равно. Они ищут одного (или, возможно, нескольких). Убедитесь, что у них есть способ добраться до этих элементов без визуальный поиск через список.
А если ваш клиент настаивает на отображении всех элементов, то обеспечьте разбиение на страницы с настраиваемым размером страницы и позвольте ему ввести «100000 элементов на страницу», если он хочет.
Я считаю себя исключением. В качестве примера я буду искать что-то в Google, а затем, когда я буду смотреть на хиты, я замечу термин, который, на мой взгляд, может быть уместным. В качестве быстрой проверки я воспользуюсь поиском в браузере, чтобы найти это слово. Лучше всего это работает с действительно большим списком.
Я еще одно исключение. Я предпочитаю огромный список и возможность сократить его с помощью поиска.
Важно отметить, что ум среднего разработчика работает в этом отношении немного иначе, чем ум среднего пользователя. Так что часто извлекать то, что хотят клиенты, из того, что нужно вам, - не лучшая идея.
Я люблю длинные одностраничные списки. Одна из немногих причин, по которым я вижу перечисление - это те, которые вы указываете на производительность.
Я думаю, что ваши клиенты очень обычные и всегда на связи.
Пороговым значением будет время загрузки страницы. Когда сервер не может создать полные списки достаточно быстро или когда списки становятся настолько длинными, что браузер замедляется. (Последнее может произойти для довольно коротких списков, если в вашем CSS есть элементы, не связанные с тегом, а браузер - это IE.)
Предоставьте пользователям мощную функцию поиска, и они сами сузят списки своих страниц.
В одной из основополагающих книг по веб-дизайну (извините, я забыл, какая из них) говорилось, что нельзя рассчитывать на то, что ваши пользователи прокручивают страницу вниз, потому что большинство из них не знают, как или не могут беспокоиться. Я думаю, что в более недавнем обновлении говорится, что, хотя это верно для широкой публики, можно ожидать, что некоторые секторы более технических пользователей будут прокручиваться вниз, и вы можете создавать страницы, требующие прокрутки IFF (если и только если и только если) вы знаете, что ваши пользователи могут справиться Это.
Я думаю, это никогда не было правдой.
О, это было правдой (и остается), но вам придется различать веб-сайт (который представляет некоторую информацию, которая может или не может быть интересна пользователю) и веб-приложение (где пользователь хочет получить кое-что сделано). Последнее требует большей вовлеченности.
Возможно, если ваше приложение предназначено для пожилых людей, это верно для небольшого процента из них.
Я думаю, что saua прав - этот совет был адресован сайтам, на которые вы пытаетесь привлечь людей, например, сайтам покупок. Это традиционные газеты, которые помещают материал, который привлечет внимание случайного прохожего, на первой странице над сгибом.
Я прекрасно понимаю вашу ситуацию. Я был в похожей ситуации. Я перевел бизнес-процесс с ручного управления на автоматизированный. Первоначально это проводилось с использованием таблиц Excel. Заинтересованные стороны моего программного обеспечения были в возрастной группе от 55 лет, им не нравилось что-либо ajaxy или какие-либо шаблоны пользовательского интерфейса, о которых вы говорите. В таких случаях логика восстановления данных может быть оптимизирована. Любая таблица, которая касается отметки 1K или имеет такие элементы, как капли изображений или тому подобное, должна отображаться по частям с точки зрения производительности.
- long выводит медленный рендеринг и будет похищать производительность
- Клиенты не хотят меняться в большинстве случаев, и покупатели всегда правы, если вы не можете их убедить.
- Я выставил свой порог, но он также зависит от содержимого строк.
Удачного кодирования!
Укажите длину страницы по умолчанию и настраиваемый параметр (например, в строке запроса для программного использования и / или в форме на веб-странице для интерактивного использования) для управления количеством списков на странице.
Гибкость пользователя - это хорошо. В Texas Instruments есть инструмент параметрического поиска, позволяющий инженерам-электрикам найти микросхемы, отвечающие определенным техническим характеристикам, и они включают ссылку как для «показать все» на веб-странице, так и «скачать все» в виде файла .csv. Хорошая модель, спасибо TI. То же на flickr; их API позволяет вам контролировать (в значительной степени) количество результатов, отображаемых при вызове веб-службы.
Я лично НЕНАВИЖУ веб-сайты, которые по умолчанию содержат 10 объявлений на странице без возможности их увеличения. Чтобы просмотреть их, требуется НАВСЕГДА, и я готов подождать дольше, если смогу получить все сразу.
Если это интерактивная веб-страница, я бы подумал о том, чтобы перейти к решению AJAX, которое загружает 100 за раз, поэтому есть индикатор прогресса (и пользователь может остановить его, если есть 20000 результатов).
Я согласен с PEZ, все дело в отзывчивости.
Действительно, в последнее время я видел несколько сайтов, которые позволяют пользователю получать больше данных на той же странице, нажимая «загрузить больше». Иногда это имеет смысл.
Вы, очевидно, не сторонник «Реализма, избегая предпочтений» (getreal.37signals.com/ch06_Avoid_Preferences.php). Но я. Я думаю, что сделать правильный выбор для ваших пользователей, чтобы им не приходилось делать это, - лучшая помощь, которую вы можете им оказать.