왜 Live Activity 미리보기가 필요했나 여행 앱에서 iOS Live Activity를 구현하고 나면, 사용자에게 표시 모드를 선택하게 하는 설정 화면이 필요하다. 일정 모드, 예산 모드, 자동 모드, 결합 모드 — 이렇게 네 가지 옵션이 있는데, 문제는 이 모드를 바꿨을 때 잠금화면에서 실제로 어떻게 보이는지 사용자가 알 수 없다는 점이었다. 설정 화면 하단에 Dynamic Island compact 형태의 간단한 미리보기는 있었다. 하지만 사용자가 Live Activity를 가장 많이 보는 곳은 잠금화면이다. 작은 알약 모양 미리보기로는 “이 모드를 선택하면 잠금화면이 이렇게 바뀝니다"를 전달하기 어려웠다. ...
스터디를 운영하다 보면 세션 중간에 즉석으로 과제를 내야 할 때가 있다. 기존 관리자 페이지를 통하면 여러 단계를 거쳐야 하고, 멘티들은 새 과제가 생긴 걸 바로 알 수 없다는 문제가 있었다. 이 글에서는 새 모델 없이 기존 시스템을 재활용하여 깜짝 과제 기능을 만들고, 1회성 알림 배너로 멘티에게 즉시 알려주는 구현 과정을 정리한다. 문제 정의 과제 생성이 느리다: 관리자 대시보드에서 여러 필드를 채워야 한다 멘티가 모른다: 새 과제가 생겨도 목록을 직접 확인하기 전까지 알 수 없다 1회성이어야 한다: 알림을 본 뒤에는 다시 보여주지 않아야 한다 설계 결정: 새 모델 vs 기존 모델 재활용 처음에는 QuickAssignment나 Notification 같은 새 모델을 만들 수 있었지만, 분석해보니 기존 구조로 충분했다. ...
Rails + Lookbook으로 UX Flow를 문서화하다가 “이게 뭔가…” 싶은 순간이 왔다. 각 Step이 와이어프레임 조각으로만 나오니, Lookbook 목록에서 봤을 때 전체 흐름이 전혀 안 보이는 것이다. 두 가지를 고쳤다. 각 Flow에 Mermaid 순서도 Overview Step 추가 모든 Step 템플릿 구조 리디자인 문제: Lookbook Step 프리뷰가 “맥락 없는 조각"처럼 보임 # @label Admin UX Flow # @logical_path ux_flows class UxFlows::AdminFlowPreview < ViewComponent::Preview # @label 1. Login -> Admin Dashboard def step_1_login_dashboard render_with_template end # ... end 각 step_* 메서드는 render_with_template으로 ERB 파일을 렌더링한다. ERB 파일 안에는 와이어프레임이 있고, 상단에 간단한 Step 네비게이션 바가 있다. ...
Flutter로 시민 신고 앱을 만들면서 세 가지 UX 문제를 연달아 만났다. 사진 추가 버튼이 갤러리만 열어서 카메라 촬영이 불가능한 문제 카테고리가 늘어날수록 그리드가 길어져서 스크롤이 많아지는 문제 신고 대상(일반/긴급)이 바뀌어도 버튼 색상이 바뀌지 않아서 직관성이 떨어지는 문제 각각 어떻게 풀었는지 정리한다. 문제 1: image_picker가 갤러리만 열린다 현상 사진 추가 버튼이 pickImage(source: ImageSource.gallery)만 호출해서 카메라로 찍는 게 불가능했다. 앱 자체에 카메라 권한도 있고 NSCameraUsageDescription도 있는데 UI에서 선택지를 아예 안 줬던 것. ...
Rails 8 + Inertia.js + Svelte 5 조합으로 만든 웹앱을 운영하다가, 기능은 돌아가는데 세부 UX가 들쭉날쭉하다는 걸 느꼈다. 이번 글은 전수 점검 후 우선순위 높은 4가지를 직접 고친 기록이다. 기능을 빠르게 만들다 보면 각 화면이 독립적으로 개발되고, 결과적으로 “같은 기능인데 화면마다 동작이 다른” 상태가 된다. 사용자 입장에서 이런 불일치는 앱이 정돈되지 않은 느낌을 준다. 코드의 버그는 아니지만, 분명한 UX 버그다. 문제 발견: 같은 기능인데 UI가 다르다 가장 먼저 눈에 띈 건 시작일 입력 UI가 화면마다 다르게 동작하는 문제였다. ...
웹에서 캘린더를 출력하는 기능을 만들었다. PDF와 PNG 다운로드는 완벽한데, 브라우저 인쇄 버튼만 누르면 이미지 위치가 전혀 반영되지 않았다. 같은 데이터를 쓰는데 왜 결과가 다를까? 구조: 프리뷰와 숨겨진 내보내기 타겟 캘린더 출력 페이지의 구조는 이렇다: ┌─ 화면에 보이는 영역 ─────────────────┐ │ [설정 패널] [프리뷰 영역] │ │ - 기간 선택 캘린더 미리보기 │ │ - 테마/색상 │ │ - 이미지 위치 슬라이더 │ └──────────────────────────────────────┘ ┌─ 숨겨진 내보내기 타겟 ───────────────┐ │ <div class="fixed -left-[9999px]"> │ ← 화면 밖 │ <PrintableCalendar ... /> │ │ </div> │ └──────────────────────────────────────┘ 프리뷰는 축소된 미리보기고, 실제 내보내기용 캘린더는 원본 크기로 화면 밖(-left-[9999px])에 렌더링된다. PDF/PNG는 이 숨겨진 엘리먼트를 캡처한다. ...
목록을 처음에 전부 로드하면 느리다. 사용자가 스크롤할수록 자연스럽게 다음 데이터를 불러오는 무한스크롤이 필요했다. infinite_scroll_pagination 같은 패키지도 있지만, 기존 BLoC 구조에 그대로 얹으려면 상태 설계를 패키지 방식에 맞춰야 해서 오히려 복잡해지는 경우가 있다. 외부 의존 없이 ScrollController만으로도 충분히 만들 수 있어서 그 방향으로 구현했다. 왜 Offset 기반인가 페이지네이션 방식은 두 가지다. Offset 기반 (page 번호) GET /items?page=1&per_page=20 GET /items?page=2&per_page=20 Cursor 기반 (마지막 아이템 ID) GET /items?cursor=abc123&per_page=20 Cursor 방식이 “데이터가 중간에 삽입/삭제돼도 중복/누락 없다"는 점에서 이론적으로 더 우수하다. 하지만 대상 데이터가 법령/규정처럼 자주 바뀌지 않는 정적 문서라면 Offset 방식으로 충분하다. ...
목록을 불러오고 보여주는 수준의 BLoC는 어렵지 않다. 문제는 세션 기반의 흐름, 예를 들어 “세션을 만들고 → 질문을 추가하고 → 답변을 받고 → 완료” 같은 단계적 워크플로우를 BLoC 하나로 관리할 때다. 이런 패턴은 리뷰 Q&A 시스템, 멀티스텝 설문, 온보딩 플로우 등 실무에서 자주 등장한다. 단순히 isLoading 불리언 하나로 버티다가 UX가 무너지는 경험을 해봤다면, 이 글이 도움이 될 것이다. 왜 BLoC가 복잡한 흐름에 적합한가 BLoC(Business Logic Component)의 핵심 가치는 UI와 비즈니스 로직의 완전한 분리다. 단순한 데이터 페칭에서는 이 장점이 와닿지 않는다. 하지만 상태가 여러 단계로 전이되고, 같은 화면에서 독립적인 로딩 피드백이 필요해질 때 BLoC의 구조적 이점이 드러난다. ...