스크롤바
스크롤바(scrollbar)는 상호작용 기술이자 위젯의 하나로, 계속되는 텍스트, 사진, 또는 다른 내용을 컴퓨터 모니터, 창, 뷰포트의 미리 정해진 위치(상하좌우) 안에서 스크롤할 수 있으며, 장치의 화면에서 한 번에 내용의 일부만 볼 수 있더라도 스크롤바를 움직여서 내용 전체를 볼 수 있다. 2차운 정보 공간 내에서 알려져 있거나 알려져 있지 않은 지점으로의 내비게이션 문제의 해결책을 제공한다.[1] 초창기 GUI에서는 핸들(handle)이라고도 불렀다. 컴퓨터, 그래픽 계산기, 휴대 전화, 휴대용 미디어 플레이어를 포함한 다양한 전자 기기에 존재한다. 사용자는 일부 방식의 방향 동작을 사용함으로써 스크롤바 요소를 통해 상호작용하며, 스크롤바는 해당 동작을 스크롤링 명령으로 변환하면 사용자는 스크롤바 요소와 스크롤되는 내용의 시각 업데이트를 통해 피드백을 받는다.[2]
스크롤바의 디자인들은 역사적으로 차이를 보이고 있지만, 보이는 영역의 한쪽 면이나 두 면 모두에 문서 본문을 이동하기 위한 길을 따라 드래그할 수 있는 막대를 포함하는 긴 직사각형 영역으로 표시되는 것이 보통이다. 내용물이 경계를 지나치는 방향이 어느 쪽이냐에 따라 창 안에서 수직으로나, 수평으로, 또는 그 두 가지 방향으로 동시에 배치될 수 있다. 더 정교한 조정을 위해 막대의 끝에 두 개의 화살표가 일반적으로 포함된다. "thumb"(스크롤바 막대)은 각기 다른 환경에서 다른 이름을 갖고 있다: 맥 OS X 10.4에서는 "스크롤러"(scroller)라고 부른다.[3] 자바 플랫폼에서는 "thumb" 또는 "knob"이라고 부른다. 마이크로소프트의 닷넷 문서에서는 "scroll box" 또는 "scroll thumb"이라고 부른다. 그 밖의 환경에서는 "elevator", "quint", "puck", "wiper", "grip"라고 부른다.
확대/축소 또는 다양한 애플리케이션 전용 도구와 같은 추가 기능이 있을 수 있다. GUI에 따라 썸(thumb)의 크기는 고정되거나 가변적일 수 있다. 가변적인 비례형 썸의 경우, 그 길이는 전체 트랙으로 표시되는 전체 문서의 크기에 대한 창의 크기 비율을 나타낸다. 비례형 썸은 GEM, 아미가OS 및 PC/GEOS를 포함한 여러 GUI에서 1980년대 중반부터 사용 가능했지만, 마이크로소프트는 윈도우 95에 이르러서야 이를 구현했다. 트러프(trough, 홈)를 완전히 채우는 비례형 썸은 전체 문서를 보고 있음을 나타내며, 이 시점에서 스크롤바는 일시적으로 숨겨질 수 있다. 비선형 영상 편집 소프트웨어 패키지인 Sony Vegas 등에서는 썸의 끝부분을 드래그하여 비례형 썸을 조절할 수도 있다. 이 경우 문서의 위치와 확대/축소를 동시에 조절하며, 썸의 크기는 적용된 확대/축소 정도를 나타낸다.
스크롤바는 시각적으로 유사하지만 기능적으로 다른 객체인 슬라이더와 구별되어야 한다. 슬라이더는 값을 변경하는 데 사용되지만, 스크롤바처럼 디스플레이를 변경하거나 표시되는 영역을 이동시키지는 않는다.
역사와 발전
[편집]1974년, Bravo를 사용하는 동안 커서를 왼쪽 여백으로 이동하면 커서 모양이 양방향 화살표로 바뀌어 스크롤이 가능해졌다. 왼쪽 또는 위쪽의 빨간색 버튼을 누르면 내용이 위로 스크롤되고, 커서 옆의 줄이 창의 맨 위로 올라갔다. 오른쪽 또는 아래쪽의 파란색 버튼을 누르면 내용이 아래로 스크롤되고, 창 맨 위의 줄이 커서 위치로 내려갔다. 가운데 노란색 버튼을 누르면 커서가 썸으로 바뀌어, 현재 위치 표시기와 함께 문서의 해당 백분율 지점으로 이동할 수 있었다.[4]
1977년, 스몰토크는 포커스된 창의 왼쪽에 고정된 스크롤바를 포함했다. 스크롤바의 오른쪽 절반을 클릭하면 내용이 위로 이동하고, 왼쪽 절반을 클릭하면 아래로 이동했다. 막대 중앙의 썸은 부드럽게 드래그할 수 있었으며 보이는 내용의 백분율을 보여주었는데, 이것이 최초의 비례형 스크롤바였다.[5]
1980년, Interlisp은 커서가 왼쪽으로 이동할 때 창의 왼쪽에 나타나는 스크롤바를 가졌다. 막대의 음영 처리된 썸은 보이는 내용의 백분율을 나타냈으며 가운데 버튼으로 제어되었다. 왼쪽 버튼은 선택한 위치를 창의 위쪽 가장자리로 이동시키기 위해 위로 스크롤했고, 오른쪽 버튼은 창의 위쪽 가장자리를 선택한 위치로 이동시키기 위해 아래로 스크롤했다.[6]
1981년에서 1982년 사이, 제록스 스타는 방해를 줄이고 시각적 혼란을 최소화하기 위해 스크롤바를 오른쪽으로 옮겼다. 사용자 연구에 따라 스크롤 화살표는 내용이 이동할 방향을 안쪽으로 가리켰으며, + 및 – 버튼을 통해 페이지 단위로 스크롤할 수 있었다. 썸은 문서의 가시 범위와 관계없이 고정된 크기의 다이아몬드 형태였다. 썸 엘리베이터 영역을 클릭하면 문서의 해당 부분으로 이동했다.[7]
1983년, 애플 리사는 위아래를 가리키는 화살표, 페이지 버튼, 고정된 크기의 썸을 가졌다.
1984년, 매킨토시 128K는 "스크롤 박스" 썸, "회색 영역" 트랙, 그리고 해당 화살표를 눌렀을 때 노출될 내용 방향을 가리키는 화살표가 있는 밝은 회색 직사각형을 가졌다. 화살표는 한 번 클릭하면 한 단위씩 스크롤되거나 계속 누르고 있으면 자동 반복되었다. 페이지 버튼은 제거되었으며, 대신 엘리베이터 트랙을 클릭하여 다음 섹션으로 이동할 수 있었다. 썸을 누른 상태에서 드래그하면 해당 지점으로 이동하지만, 떼기 전에 스크롤바 밖으로 멀리 이동하면 동작이 취소되었다. 창에 포커스가 없거나 전체 문서가 창 안에 다 보일 때는 빈 스크롤바가 표시되었다.[8]
1985년, GEM은 비례 크기의 "스크롤 박스" 썸을 사용했지만, 그 외의 작동 방식은 매킨토시와 동일했다. 결과적으로 오늘날의 윈도우 스크롤바와 다르지 않은 모양과 느낌을 가진 현대적인 스크롤바가 탄생했다. GEM은 클릭한 채로 유지한 후 마우스를 스크롤바에서 멀리 이동할 수 있도록 허용하여 눈과 손의 협응 문제를 줄였다. 아미가OS도 그해 말에 비례 크기의 스크롤 박스를 채택하며 뒤를 이었다.
또한 1985년, Viewpoint는 페이지 단위가 아닌 백분율이나 창 단위로 내용을 이동하기 위해 오른쪽 버튼을 사용했다.
1988년, Open Look은 화살표 키가 직접 달린 엘리베이터 썸을 만들었다. 트랙을 클릭하면 페이지 단위로 이동했고, 자동 반복을 통해 포인터를 밀어낼 수 있었다. 케이블 앵커가 문서의 시작과 끝에 배치되었으며, 엘리베이터의 중앙을 드래그할 수 있었다.[9]
1989년, NeXT는 스크롤바를 다시 창의 왼쪽으로 옮겼다.[10] 썸은 비례 크기였으며 화살표는 막대 아래쪽에 함께 모여 있었다. 동작은 자동 반복되었으며, alt 키를 누르면 창 단위로 내용이 이동했다. 썸을 드래그할 수 있었고, 드래그하는 동안 alt 키를 사용하면 움직임이 느려졌다.
1997년, PalmPilot은 텍스트가 화면 경계를 벗어날 때 드래그 가능한 썸과 스타일러스로 탭할 수 있는 화살표를 모두 사용하는 전통적인 스크롤바를 포함했다. 또한 각각 위아래로 스크롤할 수 있는 두 개의 물리적 버튼도 있었다.[11]
2001년, 맥 OS X 10.0은 비례형 썸을 사용하고 두 화살표 버튼을 모두 막대 아래쪽으로 옮겼다.
2007년, 아이폰과 IOS는 웹 브라우저 및 기타 애플리케이션에 일반적인 스크롤바를 포함했지만, 이는 출력용일 뿐 상호작용할 수는 없었다. 연락처에서는 내용 사이를 건너뛸 수 있도록 글자로 된 스크롤바가 제공되었다.[12]
2011년, 맥 OS X 10.7은 막대 끝의 버튼을 제거하고 iOS 스크롤바와 더 비슷하게 보이도록 설계되었다. 맥 OS X 10.7의 출시와 함께 애플은 "자연스러운 스크롤"을 도입했는데, 이는 사용자가 두 손가락 스크롤 제스처를 사용할 때 사용자의 손가락이 움직이는 방향과 같은 방향으로 화면이 움직이는 것을 의미한다. 사용자의 손가락이 트랙패드 위로 움직이면 페이지의 내용이 위로 올라가 사용자가 페이지 아래쪽의 내용을 읽을 수 있게 되며, 그 반대도 마찬가지이다.[13]
2015년 버전의 맥용 마이크로소프트 워드에서는 사라지는 스크롤바가 도입되었다. 마우스가 막대 영역 밖에 있으면 해당 창이 포커스되어 있더라도 문서 내 위치가 더 이상 표시되지 않았다. 이 변경의 목적은 정보 계층 구조상 즉시 필요하지 않을 때 스크롤바를 숨기는 맥의 표준 디자인 관행을 따르기 위함이었다.[14]
사용법
[편집]썸 드래그
[편집]썸을 드래그하는 것은 역사적으로 스크롤바를 조작하는 전통적인 방식이다. 화면의 썸 위로 커서를 이동한 다음 길게 누르면 썸을 드래그할 수 있다. 이는 주로 트랙패드나 일반적인 마우스 또는 터치패드의 왼쪽 클릭 버튼을 사용하여 수행된다. 누른 상태에서 커서를 움직이면 스크롤바의 썸이 이동하여 페이지의 다른 섹션을 볼 수 있다.[15] OS X 10.11(및 일부 이전 OS X 버전)의 기본 애플리케이션에서는 사용자가 두 손가락 스크롤이나 화살표 키와 같은 다른 스크롤 기술을 사용하기 전까지는 사용자 인터페이스에 스크롤바가 나타나지 않는다. 따라서 사용자는 먼저 이러한 방법 중 하나로 스크롤을 한 다음, 썸이 나타나는 곳으로 커서를 이동해야 한다.
마이크로소프트 윈도우에서는 썸을 드래그하는 동안 마우스 포인터를 썸에서 약 100픽셀 이상 멀리 이동하면 스크롤 위치가 이전 상태로 초기화된다. 이는 현재 위치를 잃지 않고 페이지의 이전 섹션으로 잠시 돌아가고자 할 때 유용하다.
스크롤 휠
[편집]일반적인 마우스의 스크롤 휠을 사용할 수도 있다. 휠을 앞뒤로 굴리면 내용이 위아래로 이동한다. 내용이 스크롤되는 방향은 컴퓨터의 스크롤 설정에 의해 결정된다.[16] 대부분의 마우스에는 상하로만 스크롤되는 스크롤 휠이 있지만, 일부 마우스에는 대각선 방향을 포함하여 모든 방향(상, 하, 좌, 우)으로 스크롤할 수 있는 스크롤 휠이 달려 있다.
화살표 키
[편집]키보드의 화살표 키를 사용하여 페이지에서 위, 아래, 왼쪽 또는 오른쪽으로 스크롤할 수 있다. 이 스크롤 기술은 대개 다른 스크롤 기술에 비해 화면이 매우 느리게 스크롤된다. 화살표 키를 계속 누르고 있으면 스크롤 제한 중 하나에 도달할 때까지 페이지가 계속 스크롤된다.
트러프 클릭
[편집]썸 위나 아래의 트러프(trough)를 클릭하면 페이지의 해당 지점으로 즉시 이동하거나, 다중 페이지 내용의 경우 페이지 단위로 이동할 수 있다.[15] 트러프를 클릭한 후 스크롤이 자동으로 시작되고 썸이 마우스 포인터의 위치에 도달하면 멈춘다. 이 스크롤 기술은 다른 방식보다 빠르며, 사용자가 한꺼번에 많은 내용을 스크롤해야 하거나 페이지의 정확히 어디로 스크롤해야 하는지 알고 있을 때 가장 좋다.
화면상의 화살표 버튼
[편집]마이크로소프트 워드 및 PowerPoint와 같은 많은 애플리케이션에는 스크롤을 위해 화면에 방향 화살표가 있는 스크롤바가 포함되어 있다. 화살표를 클릭하면 한 번에 내용의 적은 양(주로 한 줄)이 스크롤되며, 커서로 화살표를 계속 누르고 있으면 손을 뗄 때까지 페이지의 더 많은 영역을 연속적으로 스크롤한다.[15] 때로는 썸을 드래그하거나 마우스를 다른 쪽 화살표까지 멀리 이동하지 않고도 빠르고 정밀하게 조작할 수 있도록 두 화살표 버튼이 서로 옆에 붙어 나타나기도 한다(맥 OS 8.5에서 옵션으로 제공됨). 이들 중 하나는 막대의 양쪽 끝에 모두 표시되도록 복제될 수도 있는데, 이는 분리된 버튼과 인접한 버튼 모두에 익숙한 사용자들에게 편의를 제공한다. 이러한 화살표 버튼은 트랙패드 제스처와 스크롤 휠 마우스를 선호하여 삭제된 맥 OS X 10.7 전까지 존재했다.[17]
BeOS에서는 양방향 스크롤 버튼이 스크롤바의 양쪽 끝에 모두 나타난다. 여러 마이크로소프트 오피스 프로그램에서는 ⏪ 및 ⏩와 같은 추가 버튼을 페이지별 탐색에 사용할 수 있다.[18]
다른 마우스 버튼 사용
[편집]스크롤바를 사용하는 또 다른 기술은 어떤 마우스 버튼을 눌렀는지 확인하는 것이다. 예를 들어, 아래쪽 화살표를 왼쪽 클릭하면 창이 아래로 스크롤되는 반면, 같은 위치를 오른쪽 클릭하면 위로 스크롤되거나(예: RISC OS), 가운데 버튼을 사용하여 썸을 정밀하게 배치할 수 있다. 이 방식은 정교한 운동 기능을 덜 요구하지만, 다버튼 마우스가 필요하며 아마도 더 높은 수준의 GUI 리터러시가 필요할 것이다.
윈도우 터치패드
[편집]또한, 사진에서 보는 것과 같이 일부 윈도우 지원 기기에는 터치패드 측면에 스크롤 메커니즘이 있다. 이 메커니즘을 사용하려면 스크롤 영역에 손가락을 대고 페이지를 스크롤하기 위해 위아래 또는 왼쪽 오른쪽으로 움직인다. 마찬가지로 컴퓨터의 스크롤 설정에 따라 이러한 스크롤 영역을 따라 특정 방향으로 손가락을 움직이면 그에 상응하는 다른 스크롤 방향이 나타날 수 있다.[19]
맥 트랙패드
[편집]보다 현대적인 스크롤 기술은 맥 트랙패드에서 두 손가락 스크롤을 사용하는 것이다. 이 기술에서는 같은 손의 두 손가락 끝을 트랙패드 표면에 대고 그에 따라 움직인다. 사용자가 트랙패드 스크롤 방향을 "자연스럽게"로 설정한 경우, 두 손가락을 트랙패드 위쪽으로 움직이면 페이지가 페이지 상단 방향으로 스크롤된다. 반대로 손가락을 트랙패드 아래쪽으로 움직이면 페이지가 하단 방향으로 스크롤된다. 사용자가 두 손가락을 트랙패드 위로 매우 빠르게 움직인 다음 떼는 "플릭(flick)" 동작을 하면, 페이지는 플릭한 방향으로 계속 스크롤되다가 스크롤 제한에 도달하거나 스크롤 속도가 줄어들어 결국 멈추게 된다. 이 기능을 관성(inertia)이라고 한다.
대안적 디자인
[편집]전통적인 스크롤바 디자인과 사용법에 대한 많은 변형이 제안되거나 구현되었다. 스크롤바가 창의 가시성을 제한하는 것을 피하면서도 기능을 유지하기 위해, 테더(tether, 얇은 선) 주위의 마우스 포인터 움직임과 관련된 소프트웨어 테더를 사용하는 방식이 제안되었다. 마찬가지로, 스크롤바를 내용 내 유용한 위치에 직접 배치하여 사용 공간을 줄이고 필요한 포인터 이동 거리를 단축할 수 있다.[20]
스크롤바 표시 영역 내에 시각적 및 조작적 단서를 포함하면 어떤 방향으로 스크롤 이동이 가능한지, 그리고 어떤 스크롤바 상호작용이 가능한지 나타낼 수 있다.[20] 이는 목록의 끝을 알리는 빈 필드, 스크롤 버튼 비활성화, 스크롤바의 색상 변경 등이 될 수 있다.
일부 스크롤바에는 스크롤 동작이 내용의 어디까지 도달했는지 또는 도달할 것인지를 결정하는 데 도움이 되는 시각적 위치 표시기가 포함되어 있다.[21] 다중 페이지 내용의 경우, 스크롤이 진행됨에 따라 현재 페이지 번호 대 전체 페이지 번호를 나타내는 표시기가 썸 옆에 포함될 수 있으며, 폭이 넓은 스크롤바에는 전체 페이지의 개요가 포함될 수 있다. 알파벳 문자로 구성된 전화번호부 연락처 목록에서 사용되는 것과 같은 스크롤바에서는 현재 영역에 해당하는 문자를 더 크게 표시하거나 강조할 수 있다. 이러한 기능들은 안정적이며 애플리케이션에서 제공하는 것이지만, 일부 애플리케이션과 검색 엔진은 사용자가 제공하거나 추가한 관련성 마커를 사용할 수 있게 한다. 이들은 순수하게 시각적일 수도 있고, 각 마커에 도달할 때마다 스크롤바 내의 동작을 자동으로 멈추게 할 수도 있다.[20] 이들은 색상이나 심지어 소리로 강조되어 사용자가 내용 내에서 필요한 것을 더 잘 찾을 수 있도록 도와줄 수 있다.
동시 2차원 스크롤
[편집]특수한 스크롤바 형태의 GUI 위젯은 평면상의 어느 방향으로든 단일 직사각형을 이동시킴으로써 2차원 공간을 팬(pan)할 수 있게 해준다. 예를 들어, GTK+의 GtkScrollpane은 텍스트 뷰어 gv 및 ghostview에 구현되어 있다.
동시 2차원 스크롤의 또 다른 예는 단백질 서열 정렬 프로그램이다.[22] 처음에는 수평 스크롤바가 일반적인 것처럼 보이지만, 이후 스크롤바는 세 가지 추가 기능을 제공한다:
- 전체 장면의 개요를 제공한다.
- 높이를 확대할 수 있다.
- 노브(knob)를 좌우뿐만 아니라 수직 스크롤을 위해 상하로도 움직일 수 있다.
RISC OS에서 스크롤바를 마우스 왼쪽 버튼으로 드래그하면 일반적인 방식으로 작동하지만, 오른쪽 버튼으로 드래그하면 포인터가 사라지고 두 스크롤바를 동시에 조작할 수 있게 된다. RISC OS의 많은 GUI 작업은 오른쪽 클릭 시 관련이 있지만 약간 다른 기능을 수행한다.
개인화
[편집]
스크롤바의 모양과 기능을 개인화하는 능력과 구체적인 방법은 개인화하려는 운영체제나 응용 소프트웨어에 따라 크게 달라질 수 있다. 웹 페이지에서 스크롤바의 모양을 바꾸는 일반적인 방법은 CSS 지시어를 사용하여 스크롤바 색상을 변경하는 것이다. 이는 비표준 방식이며 마이크로소프트 인터넷 익스플로러 5.x 이상 버전과 오페라에서만 지원된다.[23][24] 또한 웹킷 기반 브라우저에는 다음과 같은 의사 요소(pseudo-elements)가 있다:
::-webkit-scrollbar::-webkit-scrollbar-button::-webkit-scrollbar-track::-webkit-scrollbar-track-piece::-webkit-scrollbar-thumb::-webkit-scrollbar-corner- 그리고
::-webkit-resizer
웹킷은 스크롤바의 스타일을 수정하기 위한 많은 의사 클래스(pseudo-classes)도 제공한다.[25]
스크롤바는 목록 항목에 대한 정보를 인코딩하도록 향상되기도 했다.[26] 예를 들어, 구글 크롬은 수직 스크롤바에 트러프 마크(trough marks)를 도입하여 문서 내에서 특정 검색어가 발견된 위치를 표시한다.
한계 및 문제점
[편집]컴퓨터에 익숙한 사용자들은 스크롤바에 친숙하지만, 지식이 제한적인 사람들은 도움 없이는 특히 최근의 변형된 형태를 직관적으로 이해하지 못할 수 있다.[27] 숙련도와 관계없이 다양한 유형의 스크롤바와 그 상호작용에서 여러 문제가 발견될 수 있다. 디자인 측면에서, 창 크기가 이미 작은 경우 스크롤바의 존재로 인해 가시적인 내용 영역이 더욱 줄어들게 된다.[20] 최근의 사라지는 스크롤바 중 일부는 이 문제를 완화하는 데 도움이 되지만, 전통적인 방식은 특히 가로와 세로 막대가 모두 있을 때 이를 피하지 못한다.
사용 측면에서 많은 일반적인 문제는 정확도와 관련이 있다. 스크롤바와 디스플레이 사이의 매핑은 선형적이므로, 사용 정확도는 내용의 크기에 비례한다.[28] 따라서 작은 문서를 탐색하는 것이 큰 문서를 탐색하는 것보다 더 간단하다. 이는 또한 문서의 모든 부분이 동일하게 강조되며, 스크롤바 사용을 통해서는 각 부분의 중요성이 인식되지 않음을 의미한다.
내용을 보기 위해 스크롤 동작을 멈추지 않는 한, 스크롤이 내용의 어디에 도달했는지 표시되지 않는 경우가 많다. 이는 사용자가 무엇을 찾고 있는지 또는 내용의 일반적인 구성을 알고 있는지 여부와 관계없이 탐색을 어렵게 만든다. 표시기가 있는 경우에도 가시성, 수량 및 스타일의 미리 정해진 설정에 의해 제한된다.[21] 하이라이트와 같은 작업을 수행하면서 스크롤을 시도할 때, 스크롤 양이 원하는 양과 일치하지 않아 목표를 지나치거나 사용자가 여러 번 위치를 다시 조정해야 할 수 있다.[29] 큰 세트 내의 단일 페이지 상단이나 하단 근처에 위치를 잡으려 할 때도 목표를 지나치는 현상이 발생할 수 있다. 사용자가 의도한 작은 스크롤 조정이 스크롤바의 다음 페이지로 건너뛰는 자동 동작을 활성화하여 더 큰 이동으로 이어질 수도 있다.[15]
연구
[편집]1986년 윌리엄 벅스턴과 브래드 A. 마이어스의 보고서는 스크롤링, 클릭, 크기 조절을 포함한 다양한 양손 상호작용을 테스트했다. 그들의 연구에서 클릭과 크기 조절은 병렬로 수행되었다. 첫 번째 실험은 참가자들에게 선택/배치 과업을 수행하도록 했고, 두 번째 실험은 복합 탐색/선택 과업을 수행하도록 요청했다. 연구 결과, 사용자는 양손을 사용할 때 이러한 과업을 더 빠르고 병렬적으로 수행할 수 있었지만, 반드시 양손을 동시에 사용할 때만 그런 것은 아니었다. 또한 사용자가 각 손으로 수행하는 과업이 서로 더 관련이 있을수록 요청된 과업을 더 빨리 수행한다는 사실을 발견했다.[30]
같이 보기
[편집]각주
[편집]- ↑ Beard, David V.; Walker II, John Q. (1990). “Navigational techniques to improve the display of large two-dimensional spaces”. 《Behavior & Information Technology》 9 (6): 451–466.
- ↑ Beaudouin-Lafon, Michel (2004). “Designing interaction, not interfaces”. 《Proceedings of the working conference on advanced visual interfaces》: 15–22.
- ↑ Apple Publications Style Guide 2008 보관됨 6월 12, 2009 - 웨이백 머신
- ↑ Lampson, Butler W. (September 1979). 《Alto Non-Programmer's Guide》 (PDF). Xerox Corporation. 34쪽.
- ↑ 《How To Use the Smalltalk-76 System》 (PDF). Xerox Corporation. October 1979.
- ↑ 《Interlisp Reference Manual》 (PDF). Xerox Corporation. October 1983.
- ↑ Dix, Alan (Spring 1998). 《Hands across the screen》. 《Interfaces》. 19–22쪽.
- ↑ Apple Computer, Inc. (1992). 《Macintosh Human Interface Guidelines》. Reading, Massachusetts: Addison-Wesley.
- ↑ Heller, Dan (1990). 《XView Programming Manual》 (PDF). O'Reilly & Associates, Inc. 2013년 4월 2일에 원본 문서 (PDF)에서 보존된 문서. 2016년 4월 27일에 확인함.
- ↑ 《Steve Jobs' New 'machine for the '90's'》. 《BYTE》. 1988. 6쪽.
- ↑ 《PalmPilot Handbook》 (PDF). 3Com Corporation. 1997.
- ↑ 《iPhone User Guide》 (PDF). Apple Inc. 2011.
- ↑ Hamburger, Ellis. “Here's Why Mac OS X Lion's "Natural Scrolling" Feels So Horribly Unnatural”. 《Business Insider》. Business Insider Inc.
- ↑ “Word 2016 For Mac Quick Start Guide”. 《Microsoft》.
- 1 2 3 4 Bates, Cary Lee; Day, Paul Reuben. “User interface component and method of navigating across a boundary coupled to a scroll bar display element”. 《Google Patents》.
- ↑ Shu, Andy. “Scroll bar input device for mouse”. 《Google Patents》.
- ↑ Workaround for Having No Scrollbar Arrows in Mac OS X Lion
- ↑ “Windows' Scrolling Behaviour”. 《www.osnews.com》. 2009년 12월 10일.
- ↑ Hoffman, Chris. “How To Use Windows 8's Gestures on a Laptop Trackpad”. 《How to Geek》. How-To Geek LLC.
- 1 2 3 4 Mishra, Umakant (2014). 《10 Inventions on scrolling and scrollbars in Graphical User Interface A TRIZ based analysis》.
- 1 2 Rowley, Daniel S.; Chapman, Leigh. “Method and system for providing an intelligent visual scrollbar position indicator”. 《Google Patents》.
- ↑ 3d-alignment.eu
- ↑ Opera's Settings File Explained
- ↑ Scrollbar-Base-Color – Cascading Style Sheets Properties
- ↑ “Styling Scrollbars”. 2009년 3월 19일.
- ↑ McCrickard, D.S.; Catrambone, R. (1999). 〈Beyond the scrollbar: An evolution and evaluation of alternative navigation techniques〉. 《Proceedings 1999 IEEE Symposium on Visual Languages》. 270–277쪽. doi:10.1109/VL.1999.795913. ISBN 0-7695-0216-4. S2CID 5715116.
- ↑ Berstis, Viktors; James, Donald A.; Radhakrishnan, Sockalinga; Xavier, James. “Replacement of traditional scroll bar with a "more" bar”. 《Google Patents》.
- ↑ Bates, Cary L.; Day, Paul R. “Computer system, user interface component and method utilizing non-linear scroll bar”. 《Google Patents》.
- ↑ Holehan, Steven D. “Computer keyboard scroll bar control”. 《Google Patents》.
- ↑ Buxton, William; Myers, Brad (April 1986). 〈A Study in Two-Handed Input〉. 《Proceedings SIGCHI '86: Human Factors in Computing Systems》. Boston, MA. 321–326쪽.
