몇 년 전 지역 병원 환자용 모바일 앱을 만들었음. 사용자 중에는 고령층이 많았는데, OS 기본 날짜 선택기가 너무 불편하다는 불만이 쏟아졌음
“생년을 설정할 수가 없다”, “내 생일까지 가려면 이전 달 화살표를 720번 눌러야 했다” 같은 이야기들이 실제로 있었음
iOS와 Android 모두 당시에는 연도가 단순한 제목처럼 보여서 클릭 가능한 요소로 인식되지 않았음
미적 감각 중심의 Flat Design이 UX를 망치고 있다고 느낌. Don Norman 같은 UX 전문가가 아닌, 디자이너 중심으로 OS UI가 결정되는 현실이 문제라고 생각함
결국 텍스트박스-드롭다운-텍스트박스(일-월-연도) 형태로 바꾸자 불만이 사라졌음
영국 정부의 Gov.uk 디자인팀 연구에서도 같은 결론을 냈음.
세 개의 텍스트박스(일, 월, 연도)가 가장 좋은 경험을 제공한다고 함.
구현을 위한 패턴 가이드도 있음
나도 처음 그 입력창을 쓸 때 100번 넘게 탭하다가 ‘이건 이상하다’ 싶어 검색해봤던 기억이 있음. 진짜 UX 악몽이었음
“연도가 클릭된다고??”라는 반응이 절로 나올 정도로 직관성이 없었음
나도 그 달력에서 연도 이동 방법을 몰라 한참 헤맸던 적이 있음
그런데 왜 생년월일 입력에 굳이 캘린더 피커를 썼는지 궁금함
여행 예약처럼 일정이 정해진 경우에는 “오늘”, “내일” 같은 상대적 날짜 표현이 편할 수 있음
하지만 자정 무렵 비행기를 예약할 때 “오늘”이 내 시간대 기준인지, 서버 기준인지, GMT인지 헷갈림
“오늘”, “내일” 같은 상대적 날짜는 아이디어는 좋아 보이지만 구현은 지옥임.
시간대, 서머타임, 월말(1월 31일 → 다음 달?), 자정 직후 등 예외가 너무 많음.
이런 기능을 넣기 전엔 정말 신중해야 함
몬트리올 대중교통은 예전에 28시간제 시계를 썼음. 자정 이후 버스가 27:30 같은 식으로 표시돼서 매우 혼란스러웠음
컴퓨터가 ‘오늘’을 자정 기준으로 정의하는 게 싫음.
새벽 12시 넘어서 일하다 보면 “내일”이라는 표현이 현실 감각과 어긋남.
실제로는 “오늘 아침 이후”를 의미하는데 시스템은 다음 날로 인식함
하지만 “오늘”이든 “11월 12일”이든, 시간대가 다르면 같은 문제가 발생함
20년 넘게 datepicker를 다뤄본 경험상, 그냥 input type="text"에 포맷 힌트를 주는 게 최선임
브라우저, 접근성, 로케일 문제 등으로 고생하지 않음
커스텀 컴포넌트는 진짜 지옥의 문임. 괜히 멋 부리다 10개의 토끼굴에 빠짐
생일처럼 이미 알고 있는 날짜엔 괜찮지만, 비행기 검색처럼 “4월 초 금요일쯤”을 찾을 땐 달력이 필요함.
날짜를 시각적으로 탐색해야 하니까
어떤 포맷 힌트를 넣든 “3-9-1980”이 사용자에게 3월 9일인지 9월 3일인지 신뢰할 수 없음
이건 나쁜 조언임. ISO 8601은 과거 시점엔 괜찮지만 미래 예약이나 국경 간 일정에는 맞지 않음.
날짜 문제는 정말 복잡해서 사용 사례별 접근이 필요함
그래도 모바일에서 연도 선택이 안 되는 달력보단 훨씬 낫다고 생각함
국제화를 이야기하면서 서양식 날짜 형식만 지원하는 건 웃김
네팔 병원 시스템을 만든다면 네팔력과 일반력 둘 다 지원해야 함. 네팔력은 매우 복잡함
에티오피아는 13개월 달력을 쓰는데, 마지막 달은 5~6일짜리임
제대로 된 국제화 date picker 참고자료가 있다면 알고 싶음
날짜 입력의 맥락이 어떤 피커를 쓸지 결정해야 함
예를 들어 저녁 예약은 주말 가용성을 보기 위해 달력이 유용하지만, 생일 입력은 숫자로 빠르게 입력하는 게 효율적임
신용카드 정보를 입력할 때처럼 숫자 입력 흐름이 중요한 경우,
“월 이름 선택 → 드롭다운 → 연도 선택” 같은 과정은 리듬을 깨뜨림
그냥 숫자만 입력하는 방식이 훨씬 자연스러움. 모바일에서는 키보드가 계속 열리고 닫혀서 더 불편함
키보드로 바로 입력할 수 있는 date picker를 보니 신선함
기본 UI 대신 커스텀 피커를 강제하는 건 이상함.
특히 Android에서 iOS 스타일의 휠 회전형 시간 선택기를 웹으로 흉내 낸 건 최악임
덴마크인으로서 “Pikaday”라는 이름이 웃김. “pik”은 덴마크어로 남성 성기 속어임
“그럼 포켓몬은 덴마크에서도 인기 있나요?”라는 농담이 나올 정도였음
Date, Time, DateTime 피커만으로는 부족함 월 단위, 주 단위, 커스텀 구간 선택기도 필요함. 네이티브 폼 요소가 너무 제한적임
<input type="week">나 <input type="month">에 Firefox 지원 외에 부족한 게 있는지 궁금함
Hacker News 의견
“생년을 설정할 수가 없다”, “내 생일까지 가려면 이전 달 화살표를 720번 눌러야 했다” 같은 이야기들이 실제로 있었음
iOS와 Android 모두 당시에는 연도가 단순한 제목처럼 보여서 클릭 가능한 요소로 인식되지 않았음
미적 감각 중심의 Flat Design이 UX를 망치고 있다고 느낌. Don Norman 같은 UX 전문가가 아닌, 디자이너 중심으로 OS UI가 결정되는 현실이 문제라고 생각함
결국 텍스트박스-드롭다운-텍스트박스(일-월-연도) 형태로 바꾸자 불만이 사라졌음
세 개의 텍스트박스(일, 월, 연도)가 가장 좋은 경험을 제공한다고 함.
구현을 위한 패턴 가이드도 있음
하지만 자정 무렵 비행기를 예약할 때 “오늘”이 내 시간대 기준인지, 서버 기준인지, GMT인지 헷갈림
시간대, 서머타임, 월말(1월 31일 → 다음 달?), 자정 직후 등 예외가 너무 많음.
이런 기능을 넣기 전엔 정말 신중해야 함
새벽 12시 넘어서 일하다 보면 “내일”이라는 표현이 현실 감각과 어긋남.
실제로는 “오늘 아침 이후”를 의미하는데 시스템은 다음 날로 인식함
input type="text"에 포맷 힌트를 주는 게 최선임브라우저, 접근성, 로케일 문제 등으로 고생하지 않음
커스텀 컴포넌트는 진짜 지옥의 문임. 괜히 멋 부리다 10개의 토끼굴에 빠짐
날짜를 시각적으로 탐색해야 하니까
날짜 문제는 정말 복잡해서 사용 사례별 접근이 필요함
네팔 병원 시스템을 만든다면 네팔력과 일반력 둘 다 지원해야 함. 네팔력은 매우 복잡함
에티오피아는 13개월 달력을 쓰는데, 마지막 달은 5~6일짜리임
제대로 된 국제화 date picker 참고자료가 있다면 알고 싶음
예를 들어 저녁 예약은 주말 가용성을 보기 위해 달력이 유용하지만, 생일 입력은 숫자로 빠르게 입력하는 게 효율적임
“월 이름 선택 → 드롭다운 → 연도 선택” 같은 과정은 리듬을 깨뜨림
그냥 숫자만 입력하는 방식이 훨씬 자연스러움. 모바일에서는 키보드가 계속 열리고 닫혀서 더 불편함
기본 UI 대신 커스텀 피커를 강제하는 건 이상함.
특히 Android에서 iOS 스타일의 휠 회전형 시간 선택기를 웹으로 흉내 낸 건 최악임
월 단위, 주 단위, 커스텀 구간 선택기도 필요함. 네이티브 폼 요소가 너무 제한적임
<input type="week">나<input type="month">에 Firefox 지원 외에 부족한 게 있는지 궁금함