현대적인 iOS 내비게이션 패턴
(frankrausch.com)- iOS 앱 내비게이션은 사용자가 현재 위치와 되돌아갈 경로를 이해하도록 계층, 오버레이, 뷰 내부 흐름을 명확히 구분해야 함
- 구조적 패턴은 Drill-Down, Flat, Pyramid, Hub-and-Spoke로 나뉘며, 트리 탐색·탭 기반 분할·형제 화면 이동·허브 복귀처럼 화면 전환의 의미가 다름
- 오버레이는 주의를 끌기 위한 장치지만, 모달 여부와 마찰 수준에 따라 뒤 화면을 막는 정도와 사용자가 해야 할 행동이 달라짐
- 임베디드 내비게이션은 특정 뷰나 모달 안에 들어가야 하며, 상태 변경이나 Step-by-Step 흐름이 계층 이동처럼 보이지 않도록 설계해야 함
- 탭은 예측 가능해야 하고 Cancel은 데이터를 바로 버리면 안 되며, iOS 앱에서는 임의 이동보다 명확한 계층·상태·모달 경계를 유지하는 편이 적합함
iOS 내비게이션의 세 가지 축
- iOS 앱은 보통 여러 단계의 고정된 계층 트리로 구성됨
- 구조적 내비게이션은 사용자가 어디서 왔는지, 계층 안에서 어디에 있는지, 원래 위치로 어떻게 돌아갈지 이해하도록 돕는 역할을 함
- 오버레이는 어떤 맥락 위에도 나타날 수 있고, 다른 오버레이 위에 겹쳐 표시될 수도 있음
- 모달 오버레이는 사용자의 행동이 있기 전까지 사라지지 않으며 뒤 인터페이스를 막음
- 비모달 오버레이는 앱을 차단하지 않음
- 임베디드 내비게이션은 iOS의 구조적·공간적 모델에 맞춰 특정 뷰나 모달 오버레이 안에 포함하는 방식이 적합함
구조적 내비게이션 패턴
-
Drill-Down
- Drill-Down은 정보의 트리 구조를 단계별 목록으로 탐색하는 패턴임
- 애니메이션 전환은 열 사이의 수평 이동을 암시함
- 오른쪽 이동은 트리 계층의 더 깊은 단계로 들어가는 동작임
- 왼쪽 이동은 상위 계층으로 돌아가는 동작임
- Drill-Down 내비게이션은 모델리스(modeless) 구조라서, 저장 여부 같은 질문이 계층 탐색을 중단하지 않음
- Navigation Bar는 현재 화면의 제목을 표시하고, 목록 행의 Disclosure indicator는 더 깊은 계층으로 들어갈 수 있음을 보여줌
- Back 버튼은 상위 계층으로 돌아가는 명확한 경로이며, 공간이 허용되면 일반적인 “Back” 대신 부모 화면 제목을 라벨로 쓰는 편이 좋음
- 화면 왼쪽 가장자리에서 오른쪽으로 스와이프하는 동작은 Back 버튼과 같은 역할을 함
- 커스텀 구현은 iOS 표준처럼 screen-edge pan gesture로 제어되는 상호작용 가능하고 취소 가능한 전환을 제공해야 함
- 오른쪽에서 왼쪽으로 읽는 언어에서는 탐색 방향과 컨트롤 배치가 읽기 방향에 맞게 미러링됨
- 트리 구조는 데이터베이스 필터링을 위해 동적으로 만들 수 있음
- 음악 앱에서는 Artist, Album, Genre 같은 서로 다른 시작점에서 같은 앨범으로 Drill-Down할 수 있고 검색 인터페이스도 함께 사용할 수 있음
- Drill-Down은 macOS Finder 스타일 Miller columns의 화면당 한 열 변형임
-
Flat
- Flat 패턴은 계층을 루트 수준에서 나누고 tab bar로 표시함
- iPad에서는 sidebar로 표시할 수 있음
- 탭 바 항목은 앱의 주요 기능을 중심으로 선별되어 사용자의 기대와 앱에 대한 멘탈 모델을 형성함
- 탭 바 항목 중 하나는 항상 선택되어 있으며, 활성 선택이 앱의 메인 콘텐츠 영역에 표시되는 내용을 결정함
- 현재 선택된 탭 바 항목은 사용자 상호작용 없이 프로그램적으로 바뀌거나, 인터페이스의 다른 버튼을 탭하는 식으로 간접적으로 바뀌면 안 됨
- 탭 바는 모달 시트에 일시적으로 가려지는 경우를 제외하면 앱 전체 화면에서 계속 보임
- 탭은 필터로 쓰이거나 음악·동영상·사진 라이브러리 같은 큰 콘텐츠 컬렉션의 서로 다른 진입점으로 쓰일 수 있음
- 각 섹션은 자체 하위 계층의 내비게이션 상태를 유지함
- 탭 바 항목은 예측 가능하게 동작해야 하며, 시트를 띄우거나 동작을 실행하면 안 됨
- Hamburger 메뉴는 탭 바와 대비되는 숨겨진 내비게이션 방식임
- 전체 내비게이션 인터페이스가 작은 아이콘 뒤에 숨으면 발견 가능성이 떨어짐
- 2015년 무렵 iOS에서 유행했지만, 탭 바가 훨씬 더 발견하기 쉽다는 연구가 나오면서 앱 제작자들이 Hamburger 메뉴를 버림
- Flat 패턴은 계층을 루트 수준에서 나누고 tab bar로 표시함
-
Pyramid
- Pyramid 패턴은 부모 화면으로 돌아가지 않고 같은 계층 수준의 형제 뷰 사이를 빠르게 이동하게 함
- 미디어 앱에서는 수평 스와이프 제스처가 형제 뷰 사이 이동에 자주 쓰임
- iOS Mail 앱의 Next Message와 Previous Message 갈매기표 버튼처럼 버튼도 사용할 수 있음
- iOS Photos 앱은 Pyramid 패턴의 예시임
- 사진을 탭해 전체 화면으로 연 뒤 좌우로 스와이프해 인접 이미지를 넘김
- 작은 컬렉션에서는 page control을 사용해 전체 항목 수와 현재 항목의 형제 내 위치를 시각화함
- iOS App Switcher는 앱 사이를 빠르게 이동하는 Pyramid 패턴을 구현하며, Home 화면을 거치는 것보다 빠른 내비게이션을 제공함
-
Hub-and-Spoke
- Hub-and-Spoke 패턴은 계층 최상위에 서로 관련 없는 큰 컬렉션이 있을 때 적합함
- 전체 화면의 자식 뷰 사이를 전환하려면 항상 먼저 허브로 돌아감
- iOS Home 화면은 설치된 모든 애플리케이션의 컬렉션이며 운영체제의 신뢰할 수 있는 중립 상태 역할을 함
- 화면 하단의 Home indicator는 배우기 쉽고 항상 사용할 수 있는 탈출구로, 익숙한 Home 화면 인터페이스로 돌아가게 함
- 이 패턴은 앱 내부에서는 거의 쓰이지 않음
- 운영체제 수준에서 애플리케이션 사이에 존재하는 강한 분리만큼 앱 내부에서 강한 분리가 필요한 경우는 거의 없음
오버레이 내비게이션
-
High-Friction Modal
- High-Friction Modal 오버레이는 시트나 여러 동작이 있는 경고 대화상자처럼, 사용자가 결정을 내릴 때까지 뒤 화면을 차단함
- 이메일 작성이나 캘린더 이벤트 생성에서는 Done 또는 Send로 진행하거나 Cancel로 마음을 바꾸는 선택이 필요함
- Cancel 버튼은 어떤 상태나 데이터를 직접 버리면 안 됨
- 모달 시트에서 Cancel을 탭할 때는 안전장치로 추가 확인 대화상자를 항상 표시해야 함
- 경고 대화상자에서 Cancel은 절대 파괴적 동작이면 안 됨
- 모달은 이메일 작성이나 캘린더 이벤트 추가처럼 특정하고 독립적인 작업을 완료하는 데 집중함
-
Low-Friction Modal
- Low-Friction Modal은 시트, 메뉴, 팝오버처럼 앱의 나머지 부분을 막지만 “둘 중 하나” 결정을 요구하지 않음
- 닫기 버튼을 누르거나 시트를 아래로 스와이프하면 사라지는 식으로 쉽게 닫을 수 있어야 함
- context menu나 popover 바깥을 탭하면 사라짐
- OK 버튼 하나만 있는 경고 대화상자는 닫기 쉽지만, 낮은 마찰이 마찰 없음과 같지는 않음
- 단일 동작 경고는 가능한 한 피해야 함
- 사용자 흐름을 방해하며, 인라인 텍스트나 비모달 알림으로 대체할 수 있는 경우가 많음
-
Non-Modal
- Non-Modal 오버레이는 화면 일부를 덮지만 뒤 인터페이스를 차단하지 않음
- 비차단 방식이라 마찰이 거의 없거나 없음
- 운영체제 알림처럼 앱 외부의 트리거에 반응해 나타날 수 있음
- 자동으로 사라지는 경우에는 최소한의 방해로 한눈에 볼 수 있는 주변 정보를 제공해야 함
- 임시 비모달 오버레이에는 선택적 상호작용이 있을 수 있음
- 알림을 탭하거나, 사라지기 전에 볼륨 표시기를 스와이프해 볼륨을 바꾸는 동작이 가능함
- 나머지 애플리케이션을 차단하지 않고 자동으로 나타나거나 사라지지도 않는 오버레이는 palette라고 불릴 수 있음
임베디드 내비게이션
-
State Change
- 하나의 뷰는 여러 상태를 가질 수 있음
- 목록 뷰는 내비게이션 계층상 위치가 바뀐 것처럼 보이지 않은 채 empty, loading, populated 상태를 가질 수 있음
- 상태 변경이 실제로 계층적이지도 모달도 아닌지 확인해야 함
- 제자리 상태 변경에는 전체 화면 전환을 피해야 함
- 예시에는 목록의 편집 모드, 웹 브라우저 인터페이스, 패닝 가능한 거리 지도, 확대 가능한 이미지가 포함됨
- 뷰 옵션은 사용자 위치를 바꾸지 않고 콘텐츠 표시 방식만 바꿈
- list view와 thumbnail view 전환은 같은 맥락의 같은 정보를 서로 다른 시각화로 토글하는 것임
-
Step-by-Step
- Step-by-Step 패턴은 가이드 투어, 설정 흐름, 온보딩 튜토리얼처럼 일련의 화면을 선형 흐름으로 연결함
- 온라인 상점 결제처럼 많은 데이터를 입력해야 하는 과정에도 여러 단계가 필요함
- 순서 안에서 앞뒤로 이동하는 것은 계층 수준을 바꾸지 않으며, 이 점이 Drill-Down 패턴과 다름
- Step-by-Step 시퀀스는 모달 오버레이 안에 담아 표시하는 편이 좋음
- 이 맥락의 Back 버튼은 계층적 Drill-Down의 Back 버튼과 목적이 다름
- 프로세스는 보통 Done 또는 Close 버튼으로 완료되며, 이 버튼은 포함된 모달도 닫음
- 선택한 옵션에 따라 단계 수와 경로가 달라질 수 있음
- Wizard와 assistant는 이 패턴의 다른 이름임
- Step-by-Step 프로세스는 지루하게 느껴질 수 있음
- 사용자가 자주 수행할 것으로 예상되면 여러 단계를 하나의 뷰 안의 다른 상태로 결합해 정보 해상도를 높이고 맥락 전환을 줄이는 방안을 고려할 수 있음
-
Content-Driven
- Content-Driven 내비게이션은 하이퍼링크나 버튼이 사용자를 다른 페이지나 뷰로 순간 이동시키는 방식임
- 브라우저의 웹 내비게이션이 이 방식으로 동작함
- iOS 앱에서는 하이퍼텍스트를 표시하는 앱, 몰입형 게임, 유사한 비선형 콘텐츠를 제외하면 이 패턴을 피하는 편이 좋음
- 앱에서 하이퍼텍스트 콘텐츠를 표시해야 한다면 뒤로·앞으로 컨트롤이 있는 브라우저 인터페이스 안에 포함하는 방안을 고려할 수 있음
- 독립된 브라우저 인터페이스의 상태 변경은 애플리케이션 계층에서 예상치 못하게 위치가 바뀌는 것보다 이해하기 쉬움
- 앱 사이 이동에는 링크를 사용할 수 있음
- Deep Links는 URL scheme이나 도메인에 연결된 Universal Links를 사용해 한 앱이나 웹사이트에서 다른 앱의 깊은 계층으로 사용자를 이동시킴
참고 자료
- Apple WWDC 2022: Explore navigation design for iOS
- Jenifer Tidwell, Designing Interfaces, Third edition, O’Reilly, 2020
- Apple Human Interface Guidelines / Navigation, Archive.org, 2022-01-19
댓글과 토론
Hacker News 의견들
-
이미 많이 한 얘기지만, 이런 패턴을 잘 쓴 게 Apollo가 Reddit 공식 앱보다 훨씬 나았던 여러 이유 중 하나였음
내비게이션, 제스처, 동작이 일관적이었고, 이런 개념이 어려운 것도 아님. 그냥 지킬 만큼 신경 쓰면 되는데, 그렇게 하지 않는 앱이 너무 많아서 맥 빠짐- 좋은 앱이 되도록 최적화한 앱과, 참여율과 판매에 최적화한 앱의 차이임
슈퍼마켓이 주기적으로 진열대를 바꾸는 것과 비슷함. 내비게이션, 제스처, 동작이 일관적이면 사용자가 원하는 걸 너무 효율적으로 얻고 빠져나갈 수 있음 - 공식 Reddit 앱만큼 헷갈리는 앱은 본 적이 없고, 내 지능은 보통이라고 봄
3만 명짜리 서브레딧을 운영해서 휴대폰에서 Reddit을 쓸 수 있어야 하는데 불가능에 가까움. 모든 작업에 너무 많은 동작이 필요하고, 지금 어디에 있는지 알 수 없어서 완전 쓰레기 같음 - Steve Huffman이 Apollo를 없애는 방식으로 Reddit을 망친 건 정말 부끄러운 일임
몇 년 전 이미 Reddit을 끊었지만, 이 일이 마지막 못질이었음 - 공식 Reddit 앱은 정기적으로 길을 잃는 몇 안 되는 앱 중 하나임
메인 화면으로 돌아가는 데 정신적 에너지가 너무 많이 들어서 그냥 강제 종료하고 다시 엶 - Apollo에서도 서브레딧, 사용자 프로필, 글 같은 레이어를 무한히 쌓아 열 수 있어서 헷갈릴 수 있음
몇 단계만 지나도 첫 화면으로 돌아가려면 거기 도달할 때까지 계속 스와이프하거나 뒤로 가기를 눌러야 해서 꽤 번거로움. 모르는 마법 같은 제스처가 있을지도 모르겠음
- 좋은 앱이 되도록 최적화한 앱과, 참여율과 판매에 최적화한 앱의 차이임
-
“iOS 내비게이션 패턴”이라는 말을 보면 움찔함. 패턴이 없고, Android와 비교할 때 iOS의 최악 중 하나임
Android에서는 뒤로 가기가 쉽고 여러 의미를 가질 수 있음. 1년 넘게 iOS를 쓰고 있는데, 두 가지 뒤로 가기 “패턴” 중 하나를 눈감고 시도한 다음 손이 닿지 않는 곳의 버튼을 찾게 됨. 그래도 안 될 때가 있음
개발자에게 패턴을 맡기지 말고 운영체제 수준에서 고쳐야 함. 개발자는 사용자가 앱 일부를 떠나는 걸 원하지 않음. 예를 들어 Instagram Reels에서 뒤로 가기를 해보면 됨- “Android에서는 뒤로 가기가 쉽고 여러 의미를 가질 수 있다”는 점이 나한테는 Android의 최악 중 하나임
뒤로 가기 버튼이 무엇을 하는지 일관성이 전혀 없음. 개발자인 나도 특정 상황에서 뒤로 가기가 무엇을 해야 하는지 고민하게 됨. 이전 화면으로 가야 하는지, 드릴다운 내비게이션에서 한 단계 위로 가야 하는지 애매하고, 둘이 같을 때도 있지만 항상 그런 건 아님
때로는 내비게이션 구조에서 한 단계 위로 가고, 때로는 이전 화면으로 가며, 때로는 대화상자를 닫고, 심지어 앱을 닫기도 함. 문맥에 따라 어떤 동작도 가능하고, 여러 개가 적용될 수 있으면 어떤 건지 불명확함. 알아내는 유일한 방법은 눌러보고 무슨 일이 생기는지 보는 것뿐임
모호한 사용자 인터페이스 요소가 싫음. 무언가를 클릭할 때 어떤 동작이 실행될지 알고 싶음 - Android의 액티비티 스택 경험은 시스템 설계에서 가장 마음에 드는 부분임
깊은 일관성을 만들어 내서 내비게이션이 힘들지 않게 됨. iOS에도 같은 방식으로 내장됐으면 정말 좋았을 것 같음
액티비티 스택은 앱을 가로질러 동작하므로, 여러 앱이 함께 한 작업을 처리하더라도 뒤로 가기 제스처는 항상 바로 이전 화면으로 돌려보냄 - iOS의 뒤로 가기 버튼은 왜 그렇게 여기저기 흩어져 있는지 모르겠음
어떤 때는 왼쪽 위, 어떤 때는 왼쪽 아래, 어떤 때는 오른쪽 아래에 있고, 다른 곳에 두는 앱도 있을 것임
Android에는 한 손으로 쓸 때도 항상 닿는 운영체제 뒤로 가기 버튼이 있음. 이 방식이 훨씬 우월함 - “개발자에게 패턴을 맡기지 말고 운영체제 수준에서 고쳐야 한다”는 건 Apple이 실질적으로 불가능해서 안 한 것 같음
예를 들어 뷰의 내용을 바꿀 수 있다면, 모든 내용을 지우고 완전히 새 내용으로 바꿀 수도 있음. 사용자의 어떤 동작으로 이게 일어나면 사실상 “새 화면으로 이동”한 것과 같음. 하지만 개발자가 제안된 운영체제 API 호출인createNewView를 쓰지 않고 현재 뷰의 내용만 바꿨다면 운영체제 수준 제스처는 동작하지 않음
다만 Apple이 심사를 통과하려면 이 운영체제 API 사용을 의무화할 수는 있음. 그래도 무엇이 “뒤로 갈 수 있는 새 뷰”이고 무엇이 “내용만 바뀐 기존 뷰”인지는 어느 정도 주관적이라고 봄 - 공유 메뉴가 최악임. 사람이 그걸 어떻게 알아내야 하는지 모르겠음
연락처, 애플리케이션, 세로 방향 항목, 가로 방향 항목, 아래쪽의 기타 항목을 보여주고, 게다가 위로 끌어올려야 한다는 걸 알아낸 뒤에야 보임. 앱마다 위치도 다르고 아이콘도 “공유”나 “복사/붙여넣기”와 아무 관련이 없음
스마트폰과 함께 자란 사람들은 늘 그렇듯 적응할 수 있음. 도입 당시 40~50세가 넘지 않았다면 대체로 적응 가능함. 현대적인 것들은 대부분 끔찍하게 설계되어 있고 자주 불안정함. AppleTV도 그렇고, Wi-Fi 비밀번호를 바꾸는 얘기를 해보자는 느낌임. 버그 우회에 필요한데 왜 켜기/끄기 버튼을 눌러도 재부팅하지 않는지 모르겠음
- “Android에서는 뒤로 가기가 쉽고 여러 의미를 가질 수 있다”는 점이 나한테는 Android의 최악 중 하나임
-
관련이 충분한지는 모르겠지만, Mac과 이제 iPadOS(https://useyourloaf.com/blog/ipad-customizable-toolbars/)에서는 내장 툴바 컨트롤이 높은 수준의 사용자 지정을 지원함
Finder를 비롯한 여러 네이티브 앱에서 시험해볼 수 있음
강력한 내장 위젯은 Mac 데스크톱에서 과소평가된 요소이고, SwiftUI가 장악하면서 걱정되는 부분이기도 함. iOS에도 큰 장점이지만, 앱들이 자기만의 디자인을 입히려는 경우가 너무 흔해서 상대적으로 덜 드러남
그런데 내가 잘못 기억하는 건지, 예전 iOS 앱은 탭 막대 사용자 지정을 기본으로 지원하지 않았나 싶음. 툴바와는 분명 다르지만, 탭의 순서와 실제로 표시할 탭을 편집할 수 있게 하는 건 내장 툴바 사용자 지정의 정신적 동등물처럼 느껴졌음. 그런데 몇 년째 못 봤음
문서에 따르면 아직 있음. 이 패턴을 아직 쓰는 앱을 아는 사람이 있는지 궁금함: https://developer.apple.com/documentation/uikit/uitabbarcont...
어쨌든 탭 막대는 멋짐. 내가 써본 대부분의 Apple TV 앱이 쓰는 방식이고, 일관된 경험이 훌륭함- 초창기에는 탭을 섞고 원하는 것만 넣거나 빼는 게 꽤 흔했음
Facebook이 아직 괜찮던 시절, 아마 iOS 7쯤에는 채팅, 피드, 알림, 그룹 같은 항목을 이렇게 바꿀 수 있었던 걸로 기억함 - Apple Store와 Music 같은 여러 Apple 앱은 아래쪽 탭 막대를 쓰지만 사용자 지정은 안 됨
Apple 바깥에서 떠오르는 앱들은 오래전에 전부 발견하기 어려운 햄버거 메뉴로 넘어갔음 - Mac에서는 더 많은 앱이 표준 툴바를 썼으면 좋겠음
사용자 지정 가능성이 좋은데, 자체 구현에서는 거의 찾아보기 어려움 UITabBar는 늘 프로그래머 입장에서도 사용자 지정이 고통스럽게 제한적이었고, 사용자가 직접 바꾸는 측면은 신경 쓰는 프로젝트가 거의 없었음
Apple이 외형을 너무 강하게 잠가버려서 결국 모두가 다른 것으로 대체하게 만들었다고 봄- Music 앱 같은 iOS 앱에서 툴바를 재배열할 수 있던 기능이 아직도 그리움
Apple Music의 탭 중 2개는 문자 그대로 전혀 안 씀. 바로 플레이리스트와 앨범으로 가게 만들 수 있으면 좋겠음
- 초창기에는 탭을 섞고 원하는 것만 넣거나 빼는 게 꽤 흔했음
-
첫 항목의 “드릴다운 내비게이션은 상태가 없다”는 말은 반대로 보임
화면 N은 이전에 한 일에 의존하고, 거기로 다시 돌아갈 수도 있으니 아주 상태가 많은 구조임. 유용하려면 내부 상태를 실제로 추적해야 함. 예컨대 목록 내용은 N-1 상태에 의존하고, 그렇지 않으면 끔찍할 것임
상태 없는 UI라면 한 단계짜리 모달 같은 것임. 있거나 없거나 둘 중 하나임. 특히 일시적이고 “재개”할 방법이 없다면 더 강하게 상태 없다고 볼 수 있음
수년간 “상태 있음”이라는 말을 완전히 다른 의미로 쓰는 논의를 꽤 많이 봤고, 최근에 특히 폭발적으로 많이 봤음. 그래서 거의 아무도 서로 그 의미에 합의하지 못하고, 그 사실을 자각하는 사람도 적다는 결론에 가까워짐
여러분에게 상태 있는 UI란 무엇인지 궁금함. 그 차이가 흥미로움- “상태 있는 UI”라는 표현이 일반적으로 모호하다는 데 동의하지만, 내비게이션 맥락에서는 보통 계층 구조를 상태 없음, 액티비티 스택을 상태 있음이라고 부르는 걸 들음
iOS 같은 계층 구조에서는 모든 자식이 정확히 하나의 부모를 가져야 하므로, 현재 페이지만 알면 “뒤로” 버튼이 무엇을 할지 알 수 있음. 그 페이지에 어떻게 도착했든 계층에서 한 단계 위의 부모 페이지로 감
Android 같은 액티비티 스택에서는 현재 페이지만으로 충분하지 않고, 그 페이지에 어떻게 왔는지를 알아야 함. “뒤로” 버튼이 기록에서 뒤로 가는 것을 뜻하기 때문임
많은 웹사이트는 둘 다 지원함. 브라우저 뒤로 가기 버튼은 상태가 있고 개인 기록을 탐색하지만, 빵부스러기 같은 페이지 안 내비게이션은 보통 상태가 없어서 해당 페이지에 도달한 특정 경로에 의존하지 않음. 물론 예외도 있음. 많은 검색 인터페이스는 항목으로 들어갔다가 페이지 내 내비게이션으로 돌아가면 부모 페이지가 아니라 이전 검색어로 돌아가므로 상태가 있다고 볼 수 있음 - 나에게 상태 있는 UI는 프론트엔드가 자기 동작을 관리하기 위해 변수를 쓰는 것을 뜻함
- “상태 있는 UI”라는 표현이 일반적으로 모호하다는 데 동의하지만, 내비게이션 맥락에서는 보통 계층 구조를 상태 없음, 액티비티 스택을 상태 있음이라고 부르는 걸 들음
-
여기서 한 가지 부정확한 표현이 보임. “화면 왼쪽 가장자리에서 오른쪽으로 스와이프하면 뒤로 버튼을 누르는 것과 같다”는 부분임
직접 구현한다면 이건 스와이프 제스처가 아니라 가장자리 팬 제스처여야 함. 손가락을 따라가고 취소 가능한 상호작용 팬이어야 하며, 그렇지 않으면 느낌이 틀어짐- X/Twitter iOS 앱과 Reddit 앱이 이 문제를 갖고 있는 것 같음
뭔가를 열심히 입력하다가 휴대폰 가장자리를 살짝 건드렸을 뿐인데 댓글 전체가 날아가는 일이 너무 자주 있음 - 왼쪽에서 오른쪽으로 스와이프해 뒤로 가는 건 “뒤로 버튼”을 구현하는 끔찍한 방식이고 절대 해서는 안 됨. 항상 실제 뒤로 가기 버튼이 있어야 함
이유는 왼손잡이가 존재하기 때문임. 왼손 엄지로 하기에는 자연스럽지도 편하지도 않은 움직임. 왼손잡이를 위해 방향을 반대로 할 수도 없음. 왼쪽에서 오른쪽으로 읽는다면 오른쪽 스와이프는 뒤가 아니라 앞으로 가는 것처럼 보이기 때문임
전반적으로 스와이프로 탐색하는 걸 좋아하지 않음. iOS에서는 특히 나쁨. 아래에서 위로 스와이프하면 어떤 메뉴가 올라오는데, 실제로 중요한 것들이 들어 있지만 필요할 때는 찾을 수 없고 웹페이지를 스크롤할 때는 계속 잘못 실행됨
더 일반적으로 iOS는 탐색하기 악몽 같은, 끔찍하게 복잡한 운영체제로 퇴화했고 Apple이 다시 UI/UX를 진지하게 다뤄야 한다고 느낌. 주된 문제는 휴대폰이 애초에 적합하지 않은 수많은 작업을 처리해야 한다는 기대처럼 보임 - Sailfish OS는 이걸 모든 앱에서 제대로, 일관되게 처리함
https://sailfishos.org/
전반적으로 iOS와 Android보다 더 단순하고 낫다고 느낌
- X/Twitter iOS 앱과 Reddit 앱이 이 문제를 갖고 있는 것 같음
-
시각적인 소프트웨어 측면에서 어려움을 겪는 사람에게 정말 좋은 자료임
다이어그램과 명확한 설명이 훌륭함 -
Frank Rausch는 최고의 Wikipedia 앱인 “V for Wiki”를 만든 사람임
그래서 그가 iOS 디자인과 사용자 경험을 이야기하면 들을 만하다고 봄
https://web.archive.org/web/20211223231349/https://v-for-wik...- 별개로 V For Wiki는 대체 무슨 일이 있었는지 모르겠음
매일 쓰다가 어느 날 갑자기 동작을 멈췄고, App Store에서 찾아보니 사라져 있었음. 정말 속상했음
- 별개로 V For Wiki는 대체 무슨 일이 있었는지 모르겠음
-
“화면 왼쪽 가장자리에서 오른쪽으로 스와이프하면 뒤로 버튼을 누르는 것과 같다”는 동작을 끌 수 있으면 좋겠음
화면에 맞지 않는 웹페이지에서 흔한 가로 스크롤을 하다가 뒤로 가기가 실행되는 일이 너무 많음 -
iOS는 이 부분을 꽤 잘함
전형적인 iOS 애플리케이션은 여러 단계의 계층 트리 같은 고정 아키텍처를 갖고, 이 엄격한 구조 덕분에 내비게이션 선택지가 예측 가능해짐. 구조적 내비게이션 패턴은 사용자가 어디서 왔는지, 계층에서 어디에 있는지, 원래 있던 곳으로 어떻게 돌아가는지에 대한 확신을 줌
반면 Android에서는 뒤로 가기 제스처가 때로는 이전 페이지로 가고, 때로는 앱을 완전히 닫아버림. 너무 일관성이 없어서 Android를 12년 쓰다가 iOS로 갈아탔음- 처음부터 그랬음
더는 못 참겠다고 결심하기 전까지 무려 12년이나 버텼다는 게 놀라움
- 처음부터 그랬음
-
처음 iPhone 개발을 시작했을 때, 즉 공식 SDK가 막 나왔을 무렵 Apple은 Human Interface Guidelines에 매우 엄격했고 좋은 UI를 만드는 요소와 따라야 할 표준 패턴에 대한 문서도 아주 좋았음
그런데 “플랫” 디자인으로 넘어가면서 그게 완전히 사라진 것 같음. 주된 이유는 더 이상 그 문서들이 말이 되지 않았기 때문이라고 봄
예전에는 “사용자 상호작용이 명확하게 보이게 하라”처럼 아주 분명했는데, 이제는 “이건 클릭 가능할 수도 있고, 그냥 텍스트일 수도 있고, 길게 눌러야 할 수도 있음”이 되어버렸음
안녕하세요! 저도 이 글을 동료에게 공유하다가 알게 되었는데요. 네비게이션이 아니라 내비게이션이 한국어 맞춤법에 맞는 표준어라고 합니다. ㅎㅎ 영어를 발음한거라 사실 어떤 것이 맞다. 라고 하기 애매할 수도 있겠지만 많은 분들이 보는 곳이니 이왕이면 표준어에 맞게 쓰여지면 좋을 것 같아 슬쩍 댓글을 달아봅니다.