브라우저와 웹앱의 뒤로가기에 대해서
최근 진행하고 있는 프로젝트에서 웹의 뒤로가기에 대한 찬반이 엇갈렸던 사건이 있었다. NextJS 프로젝트를 Progressive Web App으로 개발을 진행해, 웹이지만 데스트탑 유저가 아닌, 모바일 유저를 위한 프로젝트이다.
문제는 어플리케이션의 뒤로가기와 브라우저의 뒤로가기에 대해서 어떻게 처리할지에 대한 토의가 길어짐에 따라 많이 지쳐갔다는것, 그로 인해서 프론트엔드 팀쪽에 팀원 한명이 빠졌던것으로 연결이 되었다.
그렇기에 이 블로그에서 나의 생각을 정리해보고자 한다.
먼저, 브라우저가 뒤로가기를 어떻게 다루는지에 대해서 알아보자.
브라우저는 유저가 방문했던 사이트들을 스택의 형태로 저장하게 된다. 만약에 유저가 브라우저를 처음 켜자마자 방문했던 사이트가 webpage.com 이고, 다른곳으로도 이동을 했다. pictures.com, videos.com, naver.com, daum.com으로 말이다.
daum.com을 마지막으로, 브라우저의 기록(History)를 보자면 이렇게 생겼을 것이다.( 이하 .com을 생략)
webpage -> pictures-> videos-> naver-> [현재: daum]
유저가 뒤로가기를 누르게 된다면, 현재 브라우저가 보여주고 있는 페이지의 뒤로 가게될 것이다.
webpage-> pictures-> videos-> [현재: naver]-> daum
그리고 이 상태에서 당연히 더 뒤로 갈 수도있고, naver에서 daum으로 바로 이동할 수도 있다. 하지만 pictures까지 현재에서 뒤로가기를 두번눌렀다고 치자, 그리고 league.com에 접속하게 되면 어떻게 될까?
webpage-> pictures-> [현재: league]
이렇게 될 것이다. 현재 리스트에서 naver와 daum은 목록에서 없어졌다. 경로를 타고 올라가다가, pictures라는 분기점에서 다른 경로를 탔기 때문에, pictures에서 갔었던 naver-> daum부분은 더 이상 뒤로가기와 앞으로가기 버튼으로 접속할 수 없을것이다.
브라우저의 이러한 형태의 히스토리 저장능력은 많은 사람들을 헷갈리게 하거나, 직관적이지 못할 수도 있다. 히스토리가 저장되는 방법 또한 생각해보지 않으면 헷갈릴수도 있다고 생각을 한다. 방문했던 URL을 저장하는 하드드라이브에 저장이 되는데, 위 예시에서 볼 수 있듯이 URL을 기준으로 저장이 되게 된다.
이러한 구조는 특히 헷갈리게 되는 시점이 있는데, 바로 breadcrumbs를 사이트에서 제공해줄때다.
webpage-> pictures-> league-> [현재: league/champ]
유저는 league/champ까지 이동을 하였고, breadcrumb을 이용하여 league에 접근했다고 치자.
webpage-> pictures-> league-> league/champ-> [현재:league/]
breadcrumb을 이용하여 league을 접속했으니 위의 예시대로 history가 저장이 되었다. 하지만 여기서 유저가 뒤로가기를 누르면 어떻게 될까?
webpage-> pictures-> league-> [현재: league/champ]-> league
이러한 상태가 될 것이다. 유저는 league으로 왔고, 뒤로가기를 누르면 pictures.com으로 이동되길 원했을지도 모른다.
여기까지가 브라우저의 history navigation이였다.
그러면 내가 현재 만들고 있는 웹앱의 프로젝트는 어떨까? 우리 프로젝트는 iOS, android 운영체제를 쓰고있는 유저들을 타겟해서 만들고 있지만, 기본적으로 브라우저를 통해 실행이 될 것이다.
GUI를 통해 제공되는 뒤로가기 버튼과, url을 기준으로 브라우저의 history에 접근이 되는 브라우저의 뒤로가기 버튼 두개가 존재하고 있다. 여기서 GUI의 뒤로가기와, 브라우저의 뒤로가기가 과연 다르게 행동하는것이 옳은것인지에 대해서 논의가 이루어진것이다.
사실 개발 초기단계라, GUI의 뒤로가기가 어떤식으로 진행이 되어야하는지를 아직 정하지 못하고 있다. 하지만 생각을 해본다면, 기술적으로 무엇이 새로운 페이지인지, 아니면 직관적으로 생각했을 때 새로운 페이지가 띄워진것인지를 개발자는 유저의 입장에서 바라보고, 가장 할법한 행동에 맞춰서 기능을 개발해야 할 것이다.
이미지를 누른 후에 유저가 뒤로가기를 눌렀으면, 이미지를 누르기 전의 화면을 보여줘야하지만, 만약 이미지의 송출이 history에 기록이 되지 않는다면, 이미지를 누르기 전인 화면으로 돌아갈 것이기 때문이다.
필터링, 오버레이, 아코디언, 팝업과 게시판 이동등의 행동들이 개발자가 생각하는 새로운 페이지랑, 유저가 생각하는 새로운 페이지간의 인식의 차이를 불러 일으킬 수 있다.
나의 프로젝트는 아직 초기단계라, 명확하게 어떤것이 어떻게 개발될것인지를 아직 정하진 못했다. 하지만, 항상 유저의 생각을 입장에서 바라보고, 그에 맞춰 기술적 개발이 이루어지는것이 맞다고 생각한다.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
