무한 스크롤 웹 사이트를 구축 중지!

박사:무한 스크롤이 어떤 경우에는 솔루션을 제공하지만,그것은 사용자에게 이상적보다 적을 수 있습니다.

무한 스크롤은 혼란스럽고 통제 할 수 없으며 사용자에게 스트레스를 유발할 수 있습니다.

이 기사에서는 무한 스크롤로 웹 사이트 구축을 중단해야하는 이유를 설명합니다. 그러나 시작,의 스크롤의 간략한 역사를 살펴 보자.

스크롤의 간략한 역사

스크롤이 실제로 무엇인지 이해하기 위해 스크롤이라는 용어가 어디에서 왔는지 살펴 보겠습니다.

스크롤(엔.):기음. 1400,”양피지 또는 종이 두루마리”

원래는 정보가 길어질 때(종교적 내용처럼)사용되었습니다. 너무 많은 콘텐츠를 관리,읽기 및 쓰기가 어려워졌습니다.

컴퓨터가 우리의 삶에 왔을 때 우리는 여전히 콘텐츠의 큰 조각을 탐색 할 수있는 방법이 필요.

컴퓨터에서의 두루마리의 진화

선(및 열)

인터넷 초기에,유엑스 디자이너들은 콘텐츠를 페이징/스크롤하는 다양한 방법을 발명/탐구했다. 웹이 인기 전에,우리는 우리의 화면에 라인을 스크롤했다.

가로 스크롤 스크롤 뿐만 아니라 콘텐츠를 읽기 위한 도구 뿐만 아니라 컴퓨터 화면에서 탐색 하는 방법.

윈도우(운영체제 하나가 아님)

스크롤을 사용하여 화면을 탐색하면 사람들이 창을 만들도록 권장했습니다. 윈도우를 사용하면 한 번에 여러 콘텐츠를 볼 수 있습니다.

웹 페이지

스크롤은 웹 페이지를 탐색하는 동안 우리가 가지고있는 매우 근본적인 문제를 해결합니다. 그러나 스크롤하면 사용자에게 많은 문제가 발생할 수 있으며 사용자 환경에 부정적인 영향을 줄 수 있습니다. 자세히 살펴보겠습니다.

웹 페이지를 탐색하기 위해 발명 된 경험

나는 개발자와 디자이너가 웹 페이지에서 사용자를 탐색하기 위해 경험을 만든 방법을 정의하려고 노력할 것이다.

오프셋 기반 페이지 매김

이것은 가장 잘 알려진 페이지 매김 시스템입니다. 이 기술에서,먼저,우리는 우리가 페이지 매김을 얼마나 많은 항목을 찾을 수있다:

-- All posts countSELECT COUNT(*) AS total FROM posts

모든 항목을 계산 한 후 페이지를 계산해야합니다. 페이지 당10항목이 표시된다고 가정 해 봅시다.:

-- First page itemsSELECT * FROM posts LIMIT 10

그리고3페이지로 건너 뛰려면 먼저30항목을 건너 뛰어야합니다.OFFSET:

-- Third page itemsSELECT * FROM posts LIMIT 10 OFFSET 30

그리고 우리는 클라이언트에게 다음과 같이 매김 정보를 보낼 것입니다:

{ "pagination": { "items_count": 100, "current": 3, "total_pages": 10 }, "items": }

오프셋 기반 페이지 매김의 장단점

• 👍 좋은:모든 페이지로 이동하기 쉬운
• 좋은:클라이언트 경험이 더 무료
• 나쁜:성능 문제
• 나쁜:클라이언트 경험
• : 데이터가 변경되면 중복 항목이 표시 될 수 있습니다

커서 기반 페이지 매김

빅 데이터가 지속적으로 증가하고 있기 때문에 테이블 수를 계산하기가 어려웠습니다(트위터를 생각해보십시오). 그래서 개발자는 데이터를 페이지 매기기위한 새로운 기술 인 커서를 생각해 냈습니다.

모든 행에는 고유한 커서가 있어야 합니다. 당신은 불가능 실제 페이지 수를 알 수 있습니다 전체 테이블을 계산 할 필요가 없습니다:

-- Get extra 1 item to get its cursor.SELECT * FROM posts ORDER BY id DESC LIMIT 11

모든 게시물에 페이지 매김을 돕기 위해 고유 한 커서 필드(또는이 예제의 아이디)가 있다고 가정합니다. 클라이언트는 다음과 같이 페이지 매김 정보를 갖습니다:

{ "pagination": { "next": 1234 // extra item's ID (cursor), null if end of data. }, "items": }

커서를 사용하여 다음 페이지를 요청할 수 있습니다.:

-- Offsetting records using 1234 cursorSELECT * FROM posts WHERE id >= 1234 ORDER BY id LIMIT 11

커서 기반 페이지 매김의 장단점

• 👍 좋은:더 많은 성능,테이블 카운트 없음
• 좋은:중복 항목을 표시하는 것은 불가능 누군가가 테이블의 중앙에 행을 삽입하는 경우
• 나쁜:모든 페이지로 이동 불가능
• 나쁜:클라이언트는 경험,총 페이지와 현재 페이지가 계산되지 않습니다 무료로하지 않습니다

의 몇 가지 탐색 기술을 살펴 보자.

경험:클릭 기반

기술: 오프셋 기반 또는 커서 기반

이것은 주로 블로그를 탐색하는 데 사용됩니다. 이 무한 스크롤의 가장 오래된 버전입니다. 이 접근 방식을 사용하면 사용자는 콘텐츠가 끝나는 위치를 알 수 없습니다.

번호가 매겨진 페이지 매김

경험:클릭 기반

기술:오프셋 기반

이것은(나에 따라)가장 유용한 탐색 유형입니다. 그것은 당신이 원하는 페이지로 이동,또는 단 한 번의 클릭으로 끝 또는 시작으로 이동 할 수 있습니다 오프셋 기반의 페이지 매김을 사용합니다.

구글은 검색 결과에 이러한 종류의 탐색을 사용:

더로드

경험:클릭 트리거 기반

기술:커서 기반-오프셋 기반 일 수도 있지만 어색 할 것

이것은 최신 페이지 매김 기술 중 하나이며,또한 무한 스크롤의 이전 버전을 사용합니다.

위의 예에서 사용자는”자세히 로드”버튼을 클릭하여 더 많은 콘텐츠를 봅니다.

무한 스크롤

경험:스크롤 기반

기술:커서 기반-오프셋 기반 일 수도 있지만 매우 어색 할 것입니다

무한 스크롤은 커서 기반 페이지 매김 기술의 최신 경험입니다.

휴 이 윌리엄스는 그가 마이크로 소프트에 2005 년 무한 스크롤을 발명 주장하고있다.

메타 피지는 개발자가 무한 스크롤을 구축 할 수 있도록 도구를 만들었습니다.

무한 스크롤로 웹 사이트 구축 중지!

이 섹션까지,우리는 우리가 어떻게 여기에 왔는지 검토했습니다. 이제 왜 여기에 대해 이야기 해 봅시다.

바닥 글 찾기

바닥 글은 헤더와 마찬가지로 웹 페이지 해부학의 매우 기본적인 단위입니다. 사이트는 전화 번호,주소,도움말 및 지원 링크와 같은 일부 자세한 정보와 링크를 바닥 글에 보관합니다. 사용자가 이 자세한 정보를 검색하는 경우 대부분 아래로 스크롤하여 바닥글을 찾습니다.

무한 스크롤을 사용하면 사용자가 바닥 글을 찾기 위해 힘든 시간을 가질 수 있습니다. 무한 스크롤 불가능 페이지의 끝을 찾을 수 있습니다. 웹 사이트의 하단에 도달 할 수없는 것은 사용자가 강조 할 수 있습니다(이는 좋지 않다).

무한 피드(트위터 등)가있는 사이트는이 필요한 정보와 링크를 사이드 바에 넣는 바닥 글 문제를 해결합니다. 사이드 바는이 문제에 대한 해결책이지만 좋은 것은 아닙니다. 바닥 글은 바닥 글에 있어야합니다.

타임라인 또는 피드

소셜 미디어 응용 프로그램이 시간과 함께 작동하지 않으면 무한 스크롤을 사용하지 마십시오. 사용자의 의도는 과거를 탐색하는 것입니다. 이 경우 무한 스크롤을 사용하면 탐색이 더 쉬워집니다. 여기서 무한 스크롤은 특히 모바일에서 성능에 좋습니다.

그러나 전자 상거래,뉴스,잡지 또는 블로그 웹 사이트가 있고 사용자의 의도가 항목이나 기사를 돌아 다니는 것이라면 무한 스크롤은 악몽이됩니다. 타임 라인 기반 목록에서 사람들은 대부분 날짜 나 독특한 순간을 찾지 않습니다. 항목 기반 목록에서 사용자가 항목을 찾으려고 합니다. 무한 스크롤 사용자가 찾을 수 있도록 항목이 거의 불가능합니다.

사용자에게 더 많은 제어 권한 부여

사용자는 일반적으로 사용자가 제어 할 수 없다고 느낄 때 사용자 인터페이스가 마음에 들지 않습니다.

스크롤 이벤트는 뭔가를 할 매우 의도적 없습니다. 사용자가 페이지를 탐색하고 작업을 호출하려는 경우 대부분 클릭하거나 터치합니다(트리거라고도 함). 그들은 그들의 결정에 대해 유엔을 알려줍니다. 그러나 스크롤은 어떤 결정없이 트리거됩니다.

무한 스크롤은 사용자가 페이지를 덜 제어 할 수있게합니다. 사용자는 점프 결함이 발생할 수 있습니다.

무한 스크롤 대신 트리거 인”더로드”버튼을 넣으십시오. 이것은 사용자에게 통제를 줄 것이다. (나는 오래된 스타일의 번호가 매겨진 페이지 매김을 선호하지만 우리는 지금 커서 기반의 페이지 매김을 사용한다고 가정합니다).

사용자가 원하는 곳으로 갈 수 있도록 허용

사람들은 페이지 사이를 탐색하고,그 중 일부를 북마크하고,친구와 페이지를 공유합니다.

그러나 무한 스크롤은 설계 상 상태를 유지할 수 없습니다. 사용자는 현재 상태를 공유할 수 없으며 이는 분석 도구를 사용하여 사용자의 작업을 추적할 수 없음을 의미합니다.

백엔드 페이지 매김 기술이 커서 기반이면 사용자가 어디든 갈 수 있는 것은 거의 불가능합니다. 전자 상거래 웹 사이트가있는 경우 사용자가 원하는 제품을 탐색 할 수 있도록 제어 할 수 있습니다.

또한 목록에’정렬 기준’기능이 있는 경우 사용자에게 페이지 매김을 표시해야 합니다. 그들은 이러한 경험에 미친 갈 것입니다.

사용자가 어디에 있는지 볼 수 있도록 허용해야 합니다. 사용자는 일정 시간 동안 스크롤하며 상태 비저장 디자인이므로”다음 페이지”가 로드된 횟수를 알 수 없습니다. 그들은 페이지를 새로 고칠 때,그들은 원래 페이지로 다시 모든 방법을 재설정합니다. 그런 다음 사용자는 다시 아래로 스크롤하여 이전 위치를 찾아야합니다.

결론

무한 스크롤은 몇 가지 경우에 좋은,하지만 그들은 일반적으로 문제 해결사가 아니라 문제 업체. 사람들은 페이지 매김 문제를 해결하기 위해 무한 스크롤을 은색 총알로 간주해서는 안됩니다. 무한 스크롤 웹 사이트를 구축 중지.