Прокрутка

Если документ сколь-либо велик, он, как правило, не умещается в текстовом окне целиком.

Чтобы работать с текстом любого размера, ТП показывает в текстовом окне лишь его часть. Вы видите не весь документ, а определённый его участок. Можно “путешествовать” по документу, переходя к просмотру любого другого участка – выше, ниже, правее, левее. Это называется прокруткой (scrolling).

Чаще всего используется прокрутка по вертикали. В текстовом окне видно определённое количество строк документа. Вы можете “прокручивать” окно вверх и вниз, чтобы просмотреть весь документ.

Интересно, что “прокрутка вверх” означает, что вы идёте “ выше по тексту” – к началу документа. Строки в окне при этом перемещаются вниз. Аналогично, “прокрутка вниз” – это переход “ниже по тексту”, ближе к концу документа.

Справа от текстового окна находится “полоса прокрутки” (scroll bar). Она позволяет увидеть, в какой части документа вы сейчас находитесь. Чем ниже на ней прямоугольный индикатор, тем ближе вы к концу документа. А чем меньше размер индикатора – тем меньший участок документа вы видите. В достаточно объёмном документе один экран составляет лишь небольшую часть – в этом случае индикатор будет совсем маленьким.

Реже используется прокрутка по горизонтали. В этом случае на экране видна не вся строка документа, а лишь её часть. При этом текст невозможно читать подряд, поэтому такой режим достаточно неудобен.

Снизу от текстового окна находится горизонтальная полоса прокрутки. На ней также есть индикатор, показывающий, какая часть документа по горизонтали видна. Когда прокрутка по горизонтали не используется (показана вся ширина текста), индикатор занимает всю полосу прокрутки.

фильм: прокрутка вверх-вниз, вправо-влево

Источник

Прокрутка в вебе: букварь

Автор — Нолан Лоусон, менеджер проекта Microsoft Edge

Прокрутка — одно из самых древних взаимодействий в вебе. Задолго до появления методов pull-to-refresh и списков бесконечной загрузки скромная полоса прокрутки решила изначальную проблему масштабирования в вебе: как взаимодействовать с контентом, который распространяется за пределы доступной области просмотра?

Сегодня прокрутка всё ещё остаётся самым фундаментальным взаимодействием в Сети, и, возможно, самым неправильно понятым. Например, вы знаете разницу между следующими сценариями?

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

Многопоточный веб

Концептуально, веб является однопоточной средой. JavaScript блокирует DOM, а DOM блокирует JavaScript, потому что оба борются за один и тот же поток, часто называемый «основным потоком» или «потоком UI».

Например, если вы добавите этот (ужасный) сниппет JavaScript на страницу, то немедленно заметите ухудшение в работе:

Пока этот JavaScript крутится в бесконечном цикле, кнопки не работают, элементы форм не реагируют и даже анимированные GIF’ки тормозят — во всех смыслах и отношениях страница зависла. Можете изучить эффект в действии в простом демо.

Более того, если вы попытаетесь прокрутить страницу клавишами «вверх» и «вниз» на клавиатуре, страница предсказуемо застрянет, пока JavaScript не прекратит выполнение. Всё это явные свидетельства нашего представления веба как однопоточной среды.

Есть забавная аномалия: если попробовать прокрутку через тачскрин, то страница отлично прокручивается вверх и вниз, хотя JavaScript и блокирует всё остальное на странице. То же самое относится к прокрутке с тачпада, колесом мыши и прокрутке после захвата страницы курсором click-and-drag (в зависимости от браузера).

Каким-то образом некоторые действия по прокрутке могут изменять состояние страницы, в то время как всё остальное — кнопки, поля ввода данных, GIF’ы — полностью зависло. Как мы можем совместить это с нашей теорией однопоточного веба?

История двух потоков выполнения

Как выясняется, в целом тезис «браузеры однопоточные» правдив, но есть важные исключения. Прокрутка, во всём своём многообразии, является одним из таких исключений.

С годами разработчики браузеров осознали, что выгрузка вспомогательной работы в фоновые потоки может дать значительную выгоду по плавности работы и чувствительности. Прокрутка настолько важна для ключевого опыта работы с браузером, что эту задачу быстро выбрали для такой оптимизации. В наше время все основные браузерные движки (Blink, EdgeHTML, Gecko, WebKit) поддерживают прокрутку за пределами основного потока выполнения в той или иной степени (Firefox последним присоединился к клубу, с версии Firefox 46).

С фоновой прокруткой даже загромождённая страница будет плавно прокручиваться, потому что вся прокрутка выполняется в отдельном потоке. Только если вы попытаетесь взаимодействовать со страницей через некий посторонний механизм, не связанный с прокруткой — нажать клавишу, ввести данные в поле ввода, нажать на ссылку — тогда фасад сбрасывается и суть салонного трюка полностью раскрывает себя. (Учитывая, насколько хорошо он работает, это отличный трюк!)

Правда, у асинхронной прокрутки есть распространённый побочный эффект, который называют эффектом шахматной доски (checkerboarding). Он впервые проявился на в Safari для iOS в виде серых и белых клеток, словно с шахматной доски. В большинстве современных браузеров эффект проявляется как пустое пространство на экране, если вы осуществляете прокрутку быстрее, чем браузер может отрисовать страницу. Это не идеально, но это приемлемый компромисс, по сравнению с заблокированной, дёргающейся или неоткликающейся прокруткой.

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

Здесь будет поучительной небольшая история. Когда впервые вышли операционные системы вроде Windows и macOS, они допускали только один поток выполнения, и мало кто предвидел необходимость предусмотреть одновременный ввод. Только когда появились многоядерные машины, операционные системы начали встраивать параллелизм в свою архитектуру.

Также как рудиментарные органы животных дают понять их эволюционную историю, однопоточное происхождение операционных систем проявляет себя, если посмотреть на способы прокрутки в вебе. Только если операционная система допускает параллельный ввод — с мыши, клавиатуры или другого устройства — браузеры могут эффективно оптимизировать прокрутку, чтобы на неё не влияло длительное выполнение JavaScript, захламившего основной поток выполнения.

Однако в группе разработки Microsoft Edge мы делаем успехи, чтобы гарантировать плавный и восприимчивый скроллинг, независимо от его метода. В EdgeHTML 14 (который вошёл в состав Windows 10 Anniversary Update) мы поддерживаем фоновую прокрутку для следующих методов:

По результатам тестирования в Windows 10 (14393, Surface Book) и macOS Sierra (10.12, MacBook Air) мы получили следующие результаты:

Как демонстрирует* эта таблица, поведение прокрутки может драматически изменяться от браузера к браузеру, и даже от одной ОС к другой. Если вы тестируете один метод прокрутки только в одном браузере, то получите весьма неполные результаты производительности своего сайта, по сравнению с тем, как в реальности с ним работают пользователи!

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

Как прослушивающие процессы мешают прокрутке

Фоновая прокрутка даёт ощутимую прибавку в эффективности — прокрутка и JavaScript полностью разделены, позволяя им работать параллельно без помех друг другу.

Но каждый, кто немного разрабатывал веб-страницы, знает, как установить связь между JavaScript и прокруткой:

Менее очевидно влияние такого примера:

Прослушивание колеса мыши не взаимодействует с нашей большой блокирующей операцией JavaScript, но у них общий цикл событий, так что фоновый поток выполнения должен ждать, пока закончится более длительная операция JavaScript, прежде чем получит ответ от функции прослушивания событий.

Обратите внимание, что это относится не только к колесу мыши: на тач-устройствах прокрутка тоже может быть заблокирована прослушивающими процессами touchstart или touchmove.

Нужно быть осторожным, добавляя прослушивающие события на страницу, потому что они влияют на производительность!

Есть несколько интерфейсов JavaScript API, связанных с прокруткой, однако они не блокируют прокрутку. Событие scroll, хотя это в чём-то нелогично, не может блокировать прокрутку, потому что оно запускается после прокрутки, и поэтому является неотменяемым. Также и новый Pointer Events API, представленный в IE и Microsoft Edge, и который недавно начали внедрять в Chrome и Firefox, изначально спроектирован с целью избежать неумышленного блокирования прокрутки.

Даже в тех случаях, когда нам действительно нужно прослушивать события wheel или touchstart, есть определённые хитрости, как веб-разработчики могут гарантировать работу прокрутки с максимальным качеством. Посмотрим на некоторые из этих хитростей.

Глобальные и локальные прослушивающие процессы

В предыдущем примере мы видели случай глобального прослушивающего процесса (то есть прикреплённого к window или document). Но что насчёт прослушивающих процессов для индивидуальных элементов прокрутки?

Другими словами, представьте страницу, для которой работает прокрутка, но на странице есть отдельная область с собственной независимой прокруткой. Блокирует ли браузер прокрутку для всей страницы, если вы добавите прослушивающий процесс только в этой области?

Если вы проверите на простой демонстрационной странице, то заметите, что Microsoft Edge и Safari оставят плавную прокрутку для целого документа, если прослушивающий процесс для прокрутки находится в div с независимой прокруткой.

Вот таблица браузеров и их поведения:

Результаты показывают*, что для веб-разработчиков есть доступные оптимизации, чтобы получить пользу от этих функций браузеров. Вместо использования прослушивающих процессов wheel/touch для всего документа, предпочтительно добавить прослушивающие процессы в конкретный подраздел документа, так что прокрутка останется плавной для всех остальных частей страницы. Другими словами, вместо делегирования прослушивающих процессов wheel/touchstart на максимально высокий уровень, лучше всего изолировать их для элемента, где это нужно.

К сожалению, не все фреймворки JavaScript допускают такую практику — в частности, React, как правило, добавляет глобальный прослушивающий процесс ко всему документу даже если тот должен относиться только к части страницы. Однако есть открытый тикет конкретно для этой проблемы, и парни из React сказали, что с радостью примут пулл-реквест. (Уважение парням из React, которые так быстро среагировали на наше предложение)

Пассивный прослушивающий процесс

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

С таким подходом браузер будет обрабатывать прокрутку так, как будто прослушивающий процесс wheel вообще отсутствует. Эта функция уже доступна в последних версиях Chrome, Firefox и Safari, и должна скоро появиться в будущем релизе Microsoft Edge. (Обратите внимание, что нужно применять feature detection для поддержки браузеров, которые не распознают пассивные прослушивающие процессы).

Для некоторых событий (в том числе touchstart и touchmove) Chrome с версии 56 принял решение вмешиваться и сделал их пассивными по умолчанию. Имейте в виду эту незначительную разницу между браузерами, когда добавляете прослушивающие процессы!

Заключение

Как мы видели, прокрутка в вебе — фантастически сложный процесс, и все браузеры находятся на разных этапах улучшения своей производительности. Но в целом мы можем сформулировать некоторые чёткие советы для веб-разработчиков.

Во-первых, лучше не добавлять прослушивающие процессы wheel или touch к глобальным объектам document или window, а вместо этого добавлять их к меньшим элементам с индивидуальной прокруткой. Разработчикам также следует использовать пассивные прослушивающие процессы, где только возможно, с применением feature detection, чтобы избежать проблем совместимости. Использование Pointer Events (там есть polyfill) и прослушивающих событий scroll — тоже верный способ избежать непреднамеренной блокировки прокрутки.

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

Наша группа Microsoft Edge продолжит инновации в данной области, чтобы обеспечить плавную прокрутку для большего количества сайтов и пользователей. Скажем это для скромного скроллбара — самого старого и неоднозначного взаимодействия в вебе!

* Результаты получены на последней версии каждого браузера в феврале 2017 года. С тех пор Firefox 52 обновил поддержку прокрутки, и теперь соответствует поведению Edge 14 во всех тестах, за исключением скроллинга полосой прокрутки. Надеемся, остальные браузеры тоже сделают улучшения в реализации прокрутки и сделают веб быстрее и более восприимчивым!

Источник

Полосу прокрутки следует отличать от слайдера, который является еще одним визуально похожим, но функционально другим объектом. Ползунок используется для изменения значений, но не меняет отображение и не перемещает отображаемую область, как это делает полоса прокрутки.

Содержание

История и прогресс

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

В 1977 году Smalltalk включил стабильную полосу прокрутки в левой части окна фокуса. Щелчок по правой половине полосы прокрутки перемещает содержимое вверх, а левая половина перемещает содержимое вниз. Большой палец в центре панели можно было плавно перетаскивать и отображать процент видимого содержимого; первая пропорциональная полоса прокрутки.

В 1980 году в Interlisp была полоса прокрутки, которая появлялась в левой части окна, когда курсор перемещался влево. Заштрихованный большой палец панели показывает процент видимого содержимого и управляется средней кнопкой. Левая кнопка прокручивается вверх, чтобы переместить выбранное положение к верхнему краю окна, а правая кнопка прокручивается вниз, чтобы переместить верхний край окна в выбранное положение.

В 1983 году у Apple Lisa были стрелки, указывающие вверх и вниз, кнопки страниц и большой палец фиксированного размера.

В 1984 году у Macintosh был светло-серый прямоугольник с ползунком «ползунок», дорожкой «серая зона» и стрелками, указывающими в противоположных направлениях к контенту, который будет отображаться при нажатии соответствующей стрелки. Стрелки будут прокручивать отдельный блок при одном щелчке или автоматически повторять при непрерывном нажатии. Кнопки страниц были удалены, и вместо этого можно было щелкнуть по направляющей лифта, чтобы перейти к следующему разделу. При нажатии на большой палец, перетаскивание приведет его к этой конкретной точке, если перед отпусканием не будет сделано движение далеко за пределы полосы прокрутки, что приведет к отмене действия. Пустая полоса прокрутки отображалась, когда окно не было в фокусе или если весь документ был виден в окне.

Также в 1985 году Viewpoint использовала правую кнопку для перемещения содержимого по процентам или по окну, а не по страницам.

В 1988 году компания Open Look создала большой палец лифта со стрелками прямо на нем. Щелчок по дорожке, перемещаемой по страницам, и автоповтор толкает указатель. Кабельные анкеры размещались в начале и конце документа, а центр лифта можно было перетащить.

В 1989 году NeXT переместил полосу прокрутки обратно в левую часть окна. Большой палец был пропорционального размера со стрелками вместе внизу панели. Действия повторяются автоматически, а нажатие клавиши alt перемещает содержимое по окну. Большой палец можно было перетащить, и использование клавиши Alt во время перетаскивания замедляло его движение.

В 1997 году PalmPilot включал обычную полосу прокрутки, где текст выходил за границы экрана с использованием перетаскиваемого большого пальца и стрелок, которые можно было нажимать с помощью стилуса. Он также имел две физические кнопки для прокрутки вверх и вниз соответственно.

В 2001 году Mac OS X 10.0 использовала пропорциональный большой палец и перемещала обе кнопки со стрелками в нижнюю часть панели.

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

В 2011 году Mac OS X 10.7 удалила кнопки с конца панели и была разработана так, чтобы больше походить на полосу прокрутки iOS. В том же выпуске Mac OS X 10.7 Apple представила «естественную прокрутку», что означает, что экран перемещается в том же направлении, что и пальцы пользователя, когда они используют жест прокрутки двумя пальцами. Если пальцы пользователя перемещаются вверх по трекпаду, контент на странице поднимается вверх, позволяя пользователю читать контент дальше по странице, и наоборот.

В версии Microsoft Word для Mac 2015 года были введены исчезающие полосы прокрутки. Размещение в документе больше не было видно, когда указатель мыши находился за пределами области панели, даже если рассматриваемое окно было в фокусе. Цель этого изменения состояла в том, чтобы соответствовать стандартным методам проектирования Mac по скрытию полосы прокрутки, когда она не нужна немедленно для целей иерархии информации.

Применение

Перетаскивание пальцем

Исторически сложилось так, что перетаскивание большого пальца является традиционным способом управления полосой прокрутки. Переместив курсор на большой палец на экране, а затем нажав и удерживая, большой палец можно перетащить. Это часто делается с помощью трекпада или левой кнопки мыши на обычной мыши или сенсорной панели. Перемещение курсора при нажатии вниз перемещает ползунок полосы прокрутки для просмотра различных разделов страницы. В приложениях, родных для OS X 10.11 (и некоторых предыдущих версий OS X), полосы прокрутки не отображаются в пользовательском интерфейсе, пока пользователь не использует другой метод прокрутки, например прокрутку двумя пальцами или клавиши со стрелками. Следовательно, пользователь должен сначала выполнить прокрутку с помощью одного из этих методов, а затем переместить курсор на ползунок, где бы он ни появился.

В Microsoft Windows перемещение мыши слишком далеко от большого пальца при перетаскивании приведет к сбросу положения прокрутки на предыдущее.

Колесо прокрутки

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

Клавиши со стрелками

Кнопки со стрелками на клавиатуре можно нажимать для прокрутки страницы вверх, вниз, влево или вправо. Этот метод прокрутки обычно приводит к очень медленной прокрутке экрана по сравнению с другими методами прокрутки. Нажатие кнопок со стрелками приведет к продолжению прокрутки страницы до тех пор, пока не будет достигнут один из пределов прокрутки.

Щелчок по желобу

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

Экранные кнопки со стрелками

В BeOS экранные кнопки прокрутки для обоих направлений появляются на обоих концах полосы прокрутки. В некоторых программах Microsoft Office дополнительные кнопки ⏪ и ⏩ могут использоваться для постраничной навигации.

Различные кнопки мыши

Тачпад Windows

Кроме того, на некоторых компьютерах под управлением Windows есть механизм прокрутки сбоку сенсорной панели, как показано на рисунке. Чтобы использовать этот механизм, палец помещается в область прокрутки и перемещается вверх и вниз или влево и вправо для прокрутки страницы. Опять же, в зависимости от настроек прокрутки компьютера, перемещение пальца в определенных направлениях вдоль этих областей прокрутки может привести к различным соответствующим направлениям прокрутки.

Трекпад Mac

Альтернативные конструкции

Было предложено или реализовано множество вариантов традиционного дизайна и использования полосы прокрутки. Чтобы избежать ограничения видимости окна полосами прокрутки при сохранении функциональности, было предложено использовать программный трос (тонкая линия), связанный с перемещением указателя мыши по тросу. Точно так же полосу прокрутки можно разместить непосредственно внутри содержимого, где она будет полезна, как для уменьшения используемого пространства, так и для уменьшения необходимых перемещений указателя.

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

Некоторые полосы прокрутки включают в себя визуальный индикатор положения, который помогает определить, где действие прокрутки прошло или будет перемещаться в содержимом. Для многостраничного контента индикатор текущего номера страницы по сравнению с общим номером страницы может быть включен рядом с ползунком при прокрутке, а более широкие полосы прокрутки могут включать обзор всей страницы. В полосах прокрутки, подобных тем, которые используются в телефонных списках контактов, состоящих из букв алфавита, буква, соответствующая текущей области, может быть увеличена или выделена каким-либо образом. Хотя они стабильны и предоставляются приложением, некоторые приложения и поисковые системы позволяют использовать маркеры релевантности, предоставленные или добавленные пользователем. Они могут быть строго визуальными или могут автоматически останавливать действие на полосе прокрутки при достижении каждого маркера. Они могут быть подчеркнуты цветом или даже звуком, чтобы дополнительно помочь пользователю найти то, что ему нужно в контенте.

Одновременная 2D-прокрутка

В ОС RISC перетаскивание полосы прокрутки левой кнопкой мыши работает обычным образом, но перетаскивание правой кнопкой приводит к исчезновению указателя и одновременному манипулированию обеими полосами прокрутки. Многие операции с графическим интерфейсом пользователя в ОС RISC при щелчке правой кнопкой мыши выполняют связанные, но немного другие функции.

Настройка

WebKit также предоставляет множество псевдоклассов для изменения стиля полос прокрутки.

Полосы прокрутки также были улучшены для кодирования информации о записях списка. Например, в Google Chrome на вертикальной полосе прокрутки есть метки впадины, чтобы указать места в документе, где был найден конкретный поисковый запрос.

Ограничения и проблемы

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

С точки зрения использования, многие общие проблемы связаны с точностью. Сопоставление полосы прокрутки и дисплея является линейным, поэтому точность использования зависит от размера содержимого. Тогда навигация по меньшему документу будет проще, чем по большому документу. Это также означает, что все части документа подчеркнуты одинаково, и важность каждой части не распознается с помощью полосы прокрутки.

Нечасто указывается, где в содержимом была достигнута прокрутка, если только действие прокрутки не остановлено для просмотра содержимого. Это затрудняет независимо от того, знает ли пользователь, что он ищет, или общую организацию контента. Те, у которых есть индикатор, ограничены предопределенными настройками видимости, количества и стиля. При попытке прокрутки при выполнении такого действия, как выделение, величина прокрутки может не соответствовать желаемой величине, выходить за рамки или предлагать пользователю изменить положение несколько раз. Перерегулирование также может произойти при попытке разместить рядом с верхом или низом отдельной страницы в большом наборе. Попытка регулировки небольшой прокрутки пользователем может привести к увеличению прокрутки, поскольку прокрутка активирует автоматическое действие, переходящее на следующую страницу.

Исследования

В отчете Уильяма Бакстона и Брэда Майерса за 1986 год были протестированы различные способы взаимодействия двумя руками, включая прокрутку, щелчок и изменение размера. В их исследовании щелчок и изменение размера выполнялись параллельно. В первом эксперименте участникам предлагалось выполнить задачу выбора / позиционирования, а во втором эксперименте участникам предлагалось выполнить сложную задачу навигации / выбора. Исследование показало, что пользователи могут выполнять эти задачи быстрее и параллельно, когда они используют обе руки, но не обязательно, когда они используют обе руки одновременно. Они также обнаружили, что чем более взаимосвязанными были задачи, которые пользователь выполнял каждой рукой, тем быстрее они выполняли задачи, которые их просили выполнить.

Источник