본 포스트는 더 나은 UX를 위한 개인적 경험과 고민이 담긴 글입니다.
1. 요구사항
- 선거 조직은 [대분류]-[중분류]-[소분류]로 구분된다.
- [대분류]는 기본 값으로 "중앙자치기구", "단과대", "학과"를 갖는다.
- [대분류]인 "중앙자치기구"와 "단과대"는 [중분류]만 갖는다.
- [대분류]인 "학과"는 [중분류]와 [소분류]를 갖는다.
- "학과"의 [중분류]는 "단과대"의 [중분류]를 사용한다.
- "저장" 버튼을 누르면, 입력된 input 태그의 데이터를 서버에 전송한다.
- 데이터 전송 후, 서버에 저장된 새로운 데이터를 호출하여 UI를 최신화한다.
2. 고민
내가 고민했던 내용은 다음과 같다.
선택 1) 모든 정보를 입력한 다음, [저장하기] 버튼을 통해 최종 데이터를 전송한다.
선택 2) 각 입력마다 [저장]하여 매번 데이터를 전송한다.
*주요 쟁점
| 선택 1 : 한 번에 저장하기 | |
| 장점 | ● 저장하기 버튼을 누를 때만 네트워크 요청을 하기 때문에 네트워크 통신 횟수를 줄일 수 있다. |
| 단점 | ● 여러 데이터 입력 과정에서 의도치 않게 화면을 벗어나면, 입력 중이던 데이터를 손실할 수 있다. ● 저장하기 버튼을 따로 눌러줘야한다. |
| 선택 2 : 입력마다 저장하기 | |
| 장점 | ● 입력마다 저장하기 때문에 의도치 않게 화면을 벗어나도 데이터 손실 가능성을 줄일 수 있다. ● 버튼 클릭 없이, enter key로 빠르게 저장이 가능하다. |
| 단점 | ● 입력마다 네트워크 요청이 발생한다. |
3. 최종 선택
해당 기능을 사용하는 관리자 입장에서는 네트워크 요청을 고려할 필요가 없다는 생각이 들었다. 그리고 관리자 계정을 통해서만 관리자 페이지에 접근 가능하고, 해당 기능은 소수의 관리자만 사용하므로 네트워크 요청이 그렇게 많이 발생하지 않을 것이라 판단했다. 사용자 경험적 관점에서도 입력마다 저장되는 것이 훨씬 편리하게 느껴졌기 때문에 최종적으로는 선택 2번인 "입력마다 저장하기"를 택하게 되었다.
추가
의도치 않은 페이지 이동으로 입력 중이던 데이터가 손실되는 경우를 막기 위해 브라우저에 데이터를 주기적으로 저장하는 방식은 어떨까 생각해봤다. (물론, 사용자 입력이 많은 페이지에 한해서) localStorage와 같은 web Storage를 사용할 수 있겠지만, localStorage와 sessionStorage는 메인 스레드를 블로킹하여 동기식으로 동작하기 때문에 성능적으로 좋지 않을 것이라는 생각이 들면서, 비동기 방식인 indexDB를 사용하는 것은 어떨까라는 생각이 스쳐 지나간다. 물론, 동기식 storage에 비해 사용 방식도 복잡하고, 직접 사용해본적도 없지만, 충분히 합리적인 생각이 아닐까.
'Development > Front-End' 카테고리의 다른 글
| [프로젝트 회고] WEVOTE - 온라인 선거 관리 서비스 (0) | 2022.06.27 |
|---|---|
| [Review] 실무에서 바로 쓰는 Frontend Clean Code (0) | 2022.06.11 |
| [Review] FEConf Korea - 상태관리, 이제 Recoil 하세요 (0) | 2022.06.10 |
| [온라인 선거 홍보 서비스] 프로젝트 회고 - UNIVVOTE편 (0) | 2021.11.14 |
| Javascript Style Guide 와 ESLint에 대한 이해 (0) | 2021.11.09 |