174 lines
5.5 KiB
Markdown
174 lines
5.5 KiB
Markdown
# Mobile Web And Android Parallel UX Contract
|
|
|
|
## 목적
|
|
|
|
KoTalk는 모바일 접근을 단일 네이티브 앱으로만 보지 않는다.
|
|
초기에는 `모바일 웹/PWA`와 `안드로이드 APK`를 병렬 채널로 운영해야 하며, 두 채널이 서로를 훼손하지 않고 같은 제품 경험으로 수렴해야 한다.
|
|
|
|
이 문서는 모바일 웹과 안드로이드의 역할을 분리하면서도, 사용자가 `두 제품이 따로 논다`고 느끼지 않도록 하는 UX 계약을 정의한다.
|
|
|
|
## 왜 병렬 전략이 필요한가
|
|
|
|
- 모바일 웹은 즉시 배포와 접근성이 좋다.
|
|
- 안드로이드는 푸시, 백그라운드 안정성, 미디어 처리, 홈화면 통합에서 강하다.
|
|
- 하나만 밀면 다른 쪽의 장점을 포기하게 된다.
|
|
- 초기 오픈소스 프로젝트에서는 웹이 속도를 만들고, 네이티브가 완성도를 만든다.
|
|
|
|
## 사용자에게 보이는 원칙
|
|
|
|
- 제품 이름과 정보 구조는 동일해야 한다.
|
|
- 한국어 UI 문구, 대화 구조, 핵심 아이콘 체계는 통일한다.
|
|
- 가입과 첫 대화 시작 경험은 거의 같은 수준으로 간단해야 한다.
|
|
- 사용자는 채널 차이를 `기능 축소`가 아니라 `기기 특화`로 느껴야 한다.
|
|
|
|
## 채널별 역할
|
|
|
|
## 모바일 웹
|
|
|
|
- 즉시 접속
|
|
- 설치 없이 시작
|
|
- 링크 공유 후 빠른 확인
|
|
- 초간단 가입/초대
|
|
- 이동 중 가벼운 읽기/답장
|
|
- 릴리즈 속도가 가장 빠른 실험 채널
|
|
|
|
## 안드로이드
|
|
|
|
- 장기 세션 유지
|
|
- 안정적인 푸시
|
|
- 사진/파일/카메라 활용 강화
|
|
- 홈화면, 공유 시트, 백그라운드 복귀
|
|
- 일상적 주사용 채널
|
|
|
|
## 공통 UX 계약
|
|
|
|
### 1. 정보 구조는 같다
|
|
|
|
- 하단 내비
|
|
- 대화 목록
|
|
- 대화방
|
|
- 검색
|
|
- 보관/파일/링크
|
|
- 설정
|
|
|
|
채널마다 배치 차이는 있어도 개념 구조는 같아야 한다.
|
|
|
|
### 2. 첫 사용 60초 목표는 같다
|
|
|
|
- 이름 입력
|
|
- 초대코드 또는 간단 인증
|
|
- 자기 자신과의 대화 또는 추천 첫 대화
|
|
- 한 번 메시지 전송
|
|
|
|
### 3. 읽음과 초안은 서로 이어진다
|
|
|
|
- 모바일 웹에서 읽던 방을 안드로이드가 이어받을 수 있어야 한다.
|
|
- 안드로이드에서 쓰던 초안을 모바일 웹이 복원할 수 있어야 한다.
|
|
|
|
## 차등 UX 원칙
|
|
|
|
### 모바일 웹에서 더 단순해야 하는 것
|
|
|
|
- 설정 항목 수
|
|
- 첨부 패널 노출 수
|
|
- 배경 작업 기대치
|
|
- 장시간 세션 설명 방식
|
|
|
|
### 안드로이드에서 더 강해야 하는 것
|
|
|
|
- 푸시/알림 채널
|
|
- 카메라/갤러리 첨부
|
|
- 오프라인 복원
|
|
- 미디어 업로드 안정성
|
|
- 홈화면 바로가기와 위젯 가능성
|
|
|
|
## 화면별 계약
|
|
|
|
## 온보딩
|
|
|
|
### 모바일 웹
|
|
|
|
- 한 손 기준 하단 중심
|
|
- 텍스트 설명은 최소화
|
|
- `바로 시작` 인상이 강해야 한다
|
|
|
|
### 안드로이드
|
|
|
|
- 권한 요청은 가입 직후 몰아치지 않는다
|
|
- 푸시, 저장소, 카메라 권한은 실제 기능 직전에 요청한다
|
|
|
|
## 대화 목록
|
|
|
|
- 공통:
|
|
- 전체/안읽음/고정 필터
|
|
- 검색 진입
|
|
- 읽지 않은 수
|
|
- 고정/무음 상태
|
|
- 모바일 웹:
|
|
- 텍스트 수를 더 줄인다
|
|
- 백 버튼과 브라우저 탐색 충돌을 세심하게 처리한다
|
|
- 안드로이드:
|
|
- 스와이프 액션으로 고정/무음/보관
|
|
- 알림에서 진입한 상태 복원 강화
|
|
|
|
## 대화방
|
|
|
|
- 공통:
|
|
- 읽지 않은 구간
|
|
- 답장/반응
|
|
- 첨부
|
|
- 간단한 대화 정보
|
|
- 모바일 웹:
|
|
- 레이아웃 깨짐, 과한 너비, 상단 고정 실패를 절대 허용하지 않는다
|
|
- 브라우저 주소창 변화와 안전 영역을 고려한다
|
|
- 안드로이드:
|
|
- 키보드, IME, 제스처 네비게이션과 충돌 없는 하단 입력 경험
|
|
|
|
## 사용자 체감 리스크
|
|
|
|
실제 라이브 웹앱 관찰 기준으로 현재 가장 위험한 인상은 다음과 같다.
|
|
|
|
- 화면이 깨지면 사용자는 즉시 `프로토타입`으로 판단한다.
|
|
- 세션 오류가 노출되면 제품 전체를 불안정하게 본다.
|
|
- 온보딩에 디버그성 정보가 보이면 신뢰가 낮아진다.
|
|
- 구조가 메신저보다 데모 앱처럼 느껴지면 재방문 의사가 떨어진다.
|
|
|
|
따라서 모바일 웹은 기능 추가보다 먼저 `기본기 안정감`을 확보해야 한다.
|
|
|
|
## 병렬 운영 원칙
|
|
|
|
- 모바일 웹은 실험 선행 채널
|
|
- 안드로이드는 안정화 후 주력 채널
|
|
- 단, 실험 결과가 네이티브에 흡수될 수 있도록 설계와 용어를 공유한다
|
|
- 한 채널에만 존재하는 핵심 개념은 가능한 빨리 다른 채널 계획에 반영한다
|
|
|
|
## 릴리즈 정책
|
|
|
|
- `download-vstalk.phy.kr/windows`
|
|
- `download-vstalk.phy.kr/android`
|
|
- `vstalk.phy.kr`는 체험 및 웹 사용 경로
|
|
- Git 원격 Releases에는 Windows와 Android 산출물을 함께 게시
|
|
- README에는 웹/Windows/Android 현재 상태와 차이를 솔직히 표기
|
|
|
|
## QA 우선순위
|
|
|
|
### 모바일 웹
|
|
|
|
- 작은 화면에서 레이아웃 오버플로
|
|
- 브라우저 뒤로 가기
|
|
- 세션 만료 후 복귀
|
|
- 홈화면 추가 후 재진입
|
|
- 오프라인/불안정 네트워크
|
|
|
|
### 안드로이드
|
|
|
|
- 포그라운드/백그라운드 전환
|
|
- 푸시 탭 진입
|
|
- 첨부 업로드 중 앱 전환
|
|
- 다크 테마 강제 환경에서도 화이트 UI 가독성 유지
|
|
|
|
## 성공 기준
|
|
|
|
- 사용자가 웹을 써도 `임시판`처럼 느끼지 않아야 한다.
|
|
- 안드로이드는 웹보다 확실히 낫지만, 제품 개념 자체가 달라 보이면 안 된다.
|
|
- 두 채널 모두 `간단히 시작하고, 쉽게 읽고, 정확히 이어진다`는 공통 인상을 줘야 한다.
|