다른 웹사이트들이 새 페이지가 로딩되는 동안 현재 페이지를 완전히 표시해 두고 로딩 바가 화면을 가로지르게 하는 방식을 사용하는 것을 본 적이 있습니다. 아마 그 방식도 시도해 볼 가치가 있을 것 같습니다.
8개의 좋아요
한 가지를 더 추가하겠습니다. 저는 Discourse와 로딩 슬라이더를 사용하는 다른 일부 웹사이트 사이의 또 다른 큰 차이점을 발견한 것 같습니다. 제가 비교하는 세 웹사이트는 https://www.youtube.com, https://github.com, https://bookmeter.com입니다. 주요 차이점은 다음과 같습니다:
- 이전 게시물에서 언급했듯이, 이 웹사이트들은 교체될 콘텐츠를 빈 페이지로 바꾸지 않고, 새 콘텐츠가 로드될 때까지 이전 콘텐츠를 화면에 그대로 유지합니다(페이드 효과 등 없음).
- 일반적으로 새 페이지가 로드된 후에도 화면에 훨씬 더 많은 콘텐츠가 남아 있습니다. 이 웹사이트들은 상단 메뉴에 훨씬 더 많은 콘텐츠를 포함하고 있으며, 어떤 링크를 클릭했는지에 따라 2차 상단 메뉴가 남아 있을 수도 있습니다. 또한 새 페이지로 이동한 후에도 남아 있을 수 있는 사이드 메뉴도 있습니다. 반면 Discourse는 매우 단순한 상단 메뉴를 가지고 있으며, 검색 아이콘, 햄버거 메뉴 아이콘, 사용자 아이콘만 항상 유지됩니다.
새 콘텐츠가 준비될 때까지 기존 콘텐츠를 유지하도록 동작을 변경하는 것이 잘 작동할 수도 있습니다. 하지만 Discourse에서는 어디로 이동하든 대부분의 콘텐츠가 교체되기 때문에, 단순히 그렇게 한다고 해서 잘 작동하지 않을 수도 있습니다.
7개의 좋아요
저의 인스턴스에서는 카테고리 배너, 태그 배너, 그리고 주제 목록에서 카테고리를 표시하는 사이드바를 사용하고 있습니다. Discourse는 기본적으로 사용자 프로필이나 그룹과 같이 상단 또는 사이드바를 유지하는 일부 라우트도 제공합니다. 저는 화면에 있는 이러한 요소들이 같은 위치에 다시 나타나는 동안 단순히 숨겨지는 것을 방지하기 위해, 전환 전에 기존 뷰를 유지하는 방식을 매우 선호합니다.
7개의 좋아요
네, 저희가 약 일주일 동안 새로운 Discourse 슬라이더 테마 구성 요소를 이렇게 사용해 왔고, 정말 마음에 듭니다. 단순히 본체(body) 전환 코드를 비활성화하고 슬라이더만 사용했습니다.
페이지를 로드(또는 다시 로드)하는 브라우저의 자연스러운 동작이 전환을 처리해 주므로, HTML을 페이드아웃하거나 빈 화면으로 만드는 추가 코드는 필요하지 않습니다. 이 슬라이더는 페이드아웃이나 빈 화면 전환 등 추가 페이지 전환 코드 없이도 훌륭해 보이며, 저희 사이트에서는 이미 일주일 동안 이렇게 운영해 왔습니다.
훌륭한 슬라이더를 만들어 주셔서, 그리고 이를 테마 구성 요소로 사용자 정의할 수 있게 해 주셔서 감사합니다!
4개의 좋아요
제가 쓴 내용을 오해하셨을 수도 있지만, 제가 설명한 것은 Discourse가 현재 테마 컴포넌트를 처리하는 방식과는 다릅니다. 현재 Discourse는 새 콘텐츠가 로드되는 동안 대부분의 콘텐츠를 빈 페이지로 표시합니다. 제가 링크한 다른 웹사이트들은 새 콘텐츠가 로드되는 동안 현재 콘텐츠를 유지합니다. 이것은 같은 일이 아닙니다.
1개의 좋아요
@seanblue 님이 위에서 언급하신 내용을 정확히 이해했다고 생각합니다. 말씀하신 내용은 매우 간단하고, 제 생각에 게시글도 이해하기 쉬웠습니다.
Discourse의 원본 슬라이더 테마 컴포넌트에서 SCSS 바디 전환(애니메이션)을 주석 처리하면(FWIW, 일주일 전 포크를 통해 테마 컴포넌트를 수정했지만, 테마 컴포넌트를 수정하는 다른 방법들도 있습니다),
그럼 동작 방식은 정확히 님이 설명하신 것과 같습니다.
현재 페이지(우리의 모드에서)는 새 콘텐츠가 로딩되는 동안 표시되며, 이는 추가적인 바디 애니메이션이 없는 페이지 로딩의 일반적인 동작 방식입니다. 현재 Discourse 실험에서 보이는 "페이드아웃"과 "화면 공백"은 일주일 전 출시된 테마 버전의 CSS 바디 애니메이션 코드 때문이었습니다(아래 참조).
CSS 바디 애니메이션이 없으면, 로딩 슬라이더는 정상적인 과정을 거치며, 원래 테마 컴포넌트 CSS에 해당 애니메이션이 지정되어 있었기 때문에 바디 "화면 공백"이나 "페이드아웃"이 발생하지 않습니다. 대부분의 웹사이트(님이 언급하신 것처럼) 바디에 추가적인 애니메이션을 넣지 않으며, 그래서 님은 이렇게 말씀하신 것입니다:
이것이 “일반적인 방식”… 입니다. 이는 CSS에서 바디 애니메이션이 제거된 후 발생하는 것입니다(일주일 전 출시된 버전에 대해 말씀드리며, 저는 추적을 하지 않았는데, 즉, GitHub에 따르면 우리 수정 버전은 다음과 같습니다:
일주일 전 이 변경을 한 후, 슬라이더는 매우 훌륭해졌고(사용자들이 그렇게 말합니다) 추가적인 바디 애니메이션(페이드 인/아웃, 화면 공백 애니메이션 등)이 필요하지 않습니다.
아래는 이 멋진 슬라이더의 “최초 출시” 버전에서 주석 처리한 CSS입니다. 이 방식이 우리에게 매우 잘 작동했고(사용자들이 좋아합니다), 그래서 우리는 그것을 잘 작동하도록 만든 후의 “콤보 스피너, 화면 공백” 애니메이션, 바디 실험 코드 변경 사항을 모두 추적하지 않았습니다. meta에서 실험을 통해 제가 확인한 결과만 예외입니다.
// body #main-outlet {
// transition: opacity 0.2s ease;
// }
// body.loading #main-outlet {
// opacity: 0.2;
// transition: opacity var(--loading-duration) ease;
// }
도움이 되셨길 바랍니다.
5개의 좋아요
아, 포크/모드 버전이었군요. 실수했어요. 이 버전이 잘 작동하고 있어서 다행입니다. 다음에 메타 쪽에서도 그 방식을 시도해 보길 바랍니다.
6개의 좋아요
@david / @awesomerobot 이 문제에 대해 몇 번이나 의견이 갈렸지만, 페이드 전환 전에 원래 구현 방식(사소한 개선 사항 포함)을 먼저 시도해 봐야 한다고 생각합니다. 클릭 시 우리가 가진 옵션들을 정리해 드리면 다음과 같습니다.
- 기존 콘텐츠를 화면에 유지하다가 새 콘텐츠가 준비되면 전환합니다.
- "흰 화면"을 렌더링하다가 새 콘텐츠가 준비되면 전환합니다.
- 불투명 콘텐츠(0~40% 사이 어디든)로 전환하다가 새 콘텐츠가 준비되면 전환합니다.
이 모든 옵션에 공통적으로 추가하고 싶은 것은 "콘텐츠 로딩이 2초를 초과하면 스피너를 렌더링한다"는 것입니다.
(1)은 과도한 전환 상태를 최소화하는 유일한 해결책입니다. "아무것도 클릭했는데 아무 일도 일어나지 않는 것 같다"는 적응 과정이 약간 필요하긴 하지만, 하이퍼링크를 클릭할 때 웹이 작동하는 방식과 동일합니다. 다른 사이트로 연결되는 링크를 클릭할 때 브라우저가 흰 화면을 렌더링하거나 페이드 아웃을 하지 않듯이 말입니다.
(2)는 현재 사용하고 있는 방식이며, 일부에게는 거칠다고 여겨집니다. 이 패턴의 가장 큰 장점 중 하나는 흰 화면을 피할 수 있다는 것이기 때문입니다. 이는 기존 스피너 방식에 비해 매우 사소한 변화일 뿐입니다.
(3)는 매우 산만하게 느껴질 수 있으며, 적절한 불투명도를 찾는 것이 어렵습니다. 직접 시도해 본 경험에 따르면, 1시간만 사용해도 극도로 피로감을 느꼈습니다.
@david (2)번을 제대로 테스트해 봤으니, 이번 주 정도는 (1)번을 제대로 시도해 볼 수 있을까요? 화면 변화가 최소화되므로 이것이 가장 좋다고 생각합니다.
9개의 좋아요
이것은… 사실이 아닙니다. 클릭 즉시 로딩 애니메이션이 시작됩니다. 링크를 클릭하는 동안 브라우저의 탭을 보세요. 클릭하거나 탭할 때 즉시 파비콘에서 로딩 스피너로 전환되는 것을 확인할 수 있습니다.
5개의 좋아요
미안, 맞는데 내가 여기서 하려는 말이 바로 그거였어. 여기에서 “표준” 네비게이션에 매우 가까운 것을 시뮬레이션할 수 있어 (예를 들어 로딩 중에 탭의 아이콘을 변경하거나, 탭의 텍스트를 변경할 수 있지).
사이트에서 아무 링크나 클릭하면 현재 페이지가 100% 하얗게 되거나 불투명해지지 않아. 새 사이트의 DNS가 해석되고 콘텐츠가 렌더링될 준비가 될 때까지 기존 콘텐츠가 화면에 일정 기간 동안 남아있어.
나에게 이 컴포넌트의 큰 강점은 중간 상태를 줄이는 데 있어. 만약 이를 위장해서 표준 브라우저 네비게이션처럼 “느껴지게” 만들 수 있다면 좋을 것 같아.
12개의 좋아요
걱정 마세요. 우리는 슬라이더(데스크톱용 몇 픽셀 추가)를 정말 좋아하지만, 바디 애니메이션(화면 비우기, 페이드 인/아웃 등)은 필요 없다고 판단했습니다.
슬라이더가 로딩 상태를 충분히 잘 나타내 주고, 페이지는 자연스럽게 로딩되고 변경됩니다. 바디 전환 CSS나 추가 스피너를 넣지 않아도 되니까요. 이렇게 8~9일째 운영해 왔는데, 사용자들도 만족하고 저도 좋습니다. 사용자들은 “페이드 인/아웃” 애니메이션이나 “페이지 비우기” 애니메이션, "추가 스피너 + 슬라이더 애니메이션"을 좋아하지 않았습니다. 하지만 다시 말하지만, 우리 사용자들은 일반적으로 불필요한 애니메이션이나 추가 웹 가젯을 좋아하지 않는 편입니다.
메타 팀이 이 코드를 테마 컴포넌트로 유지해 주거나, 적어도 사이트 소유자가 최종적으로 결정된 것을 계속해서 오버라이드할 수 있도록 허용해 주었으면 합니다. 페이지 전환에 있어 우리 사용자들이 좋아하는 것과 다른 사람들이 좋아하는 것이 다른 것 같으니까요.
의심이 들 때, "부드럽게 다뤄 사이트가 선택할 수 있는 기능을 제공하라"는 좋은 접근법이라고 생각합니다.
3개의 좋아요
좋습니다, 해당 컴포넌트를 원래 구현대로 되돌렸습니다.
7개의 좋아요
2초가 지나면 스핀너를 표시하는 “아, 2초가 지났네”라는 부분은 분명 사소하지만 반드시 추가해야 할 중요한 요소라고 생각합니다.
그 외에는 사람들의 반응을 한번 지켜보겠습니다. 이 버전이 최종 배포될 가능성이 높다고 생각합니다.
8개의 좋아요
어디에 표시해야 할까요? 일종의 모달로 표시해야 할까요? 아니면 스피너를 위해 #main-outlet을 2초 후에 숨겨야 할까요?
4개의 좋아요
메인 아웃렛을 숨기는 방향으로 생각 중입니다. 임계값을 조정할 수도 있는데, 2는 다소 임의적으로 느껴지니 3, 4, 5 정도로 하는 건 어떨까요?
6개의 좋아요
스피너가 이제 2초 후에 표시됩니다:
12개의 좋아요
정말 멋진 아이디어네요. 2초 뒤에 추가 스피너 레이어가 없다면 사용자에게 어색한 상황이 생길 수 있어요. 이렇게 하면 두 가지 장점을 모두 얻을 수 있어요. 1. 슬라이더 덕분에 번개처럼 빠르다고 믿게 만드는 것 (솔직히 여기서는 TBO를 속이는 거죠). 2. 로딩이 멈췄을 때 그 공백을 메워주는 것 (심리적 전환). 잘했어요! 
8개의 좋아요
방금 시뮬레이션된 느린 네트워크 환경에서 테스트해 봤는데, 2초 후에 표시되는 스피너는 확실히 좋은 느낌입니다. 다만 데스크톱(적어도 상당히 큰 모니터)에서는 로딩 슬라이더가 거의 보이지 않는다는 점을 다시 강조하고 싶습니다. 세로로 2~3픽셀만 더 늘려도 훨씬 나아질 것 같습니다.
5개의 좋아요
저는 디스커스를 처음 사용하는 초보 사용자로서 이 대화를 지켜보고 있습니다. 이 매우 “현대적인” UX 기능에 얼마나 세심한 고민과 노력이 기울여지고 있는지 정말 인상 깊었습니다. 주제에서 벗어난 말씀이 되어 죄송하지만, 다른 포럼 소프트웨어를 수년간 사용해 온 사람으로서 이 대화는 정말 인상 깊습니다.
훌륭한 작업을 계속해 주세요… 이 기능이 정말 좋습니다.
11개의 좋아요
아까 이미 클릭했는데 잘못 눌렀다고 생각해서 다시 클릭한 걸 언급해야 할 것 같아요. 사실 처음 클릭했을 때부터 로딩 중이었거든요. 아마 로딩 스피너가 없는 데에 익숙해져야 할 것 같습니다…
5개의 좋아요