모바일을 회전하여 화면을 테스트할 때 레이아웃이 깨끗하게 적응하거나 파괴됩니다. 텍스트가 다시 흐르며 버튼이 뛰어오르거나 모달이 갑자기 잘못된 영역을 덮거나 비디오 플레이어가 예상대로 동작합니다. 그 작은 순간은 포트레이트 방향 디자인 용어에서 벗어나 제품 결정이 된다.
모바일을 위한 앱을 개발할 때는 portrait orientation에 대한 명확한 답변이 필요합니다. portrait orientation이란?클래스룸에서 배운 정의 외에도 개발자 버전의 portrait orientation을 이해해야 합니다. 레이아웃에 어떤 영향을 미치는지, 회전을 지원해야 하는지, 회전을.lock해야 하는지, 웹 앱, 네이티브 앱, Capacitor 프로젝트에서 portrait orientation을 처리하는 방법 등이 모두 포함됩니다.
목차
- portrait orientation 이해하기
- portrait vs landscape: 기본 비교
- 다양한 매체에서 일반적인 사용 사례
- 웹에서 방향 관리
- 모바일 앱에서 방향 관리
- 화면 방향 UX 최적화
포트레이트 방향 이해
사용자는 화면 회전을 처음으로 인식합니다. 개발자는 회전이 인터페이스를 깨트릴 때 이를 인식합니다.
포트레이트 방향 의 의미는 높이가 너비보다 더 높다그것이 핵심입니다. 그것은 시각 예술에서 시작되었습니다. 사람의 얼굴과 상체의 초상화는 일반적으로 세로로 프레임이었습니다. 그 동일한 개념이 페이지 디자인, 사진 촬영, 디지털 인터페이스에 이르렀습니다. 그 보다 광범위한 역사에 대한 좋은 참고 자료는 Wikipedia의 페이지 방향 개요.
빌더들에게 중요한 것은 포트레이트 방향이 하나의 화면 크기, 하나의 장치, 또는 하나의 파일 형식과 관련이 없다는 것입니다. 그것은 모양에 대한 규칙입니다. 높이가 너비보다 더 높다면, 포트레이트 방향입니다.
제품 작업에서 중요성
포트레이트 방향이 모바일에서 실용적인 기본값이 된 이유는 upright 사용이 사람의 자연스러운 휴대폰을 잡는 방식과 일치하기 때문입니다. 그것은 스크롤링, 손가락의 범위, 읽기 흐름, 양식 디자인, 및 네비게이션 위치에 영향을 줍니다.
모바일 앱 사용자 경험 결정과 직접 연결된 orientation 선택의 이유 중 하나는, feed, 기사 보기, 설정 화면, 또는 채팅 쓰레드가 일반적으로 수직 프레임에서 더 자연스럽게 읽히기 때문입니다. 모바일 앱 사용자 경험 결정과 직접 연결된 orientation 선택의 이유 중 하나는, feed, 기사 보기, 설정 화면, 또는 채팅 쓰레드가 일반적으로 수직 프레임에서 더 자연스럽게 읽히기 때문입니다.portrait orientation 선택은 사용자 경험 결정과 직접 연결된 것이 아니라, 단순히 시각적 스타일링일 뿐입니다.
실용적인 규칙: portrait를 레이아웃 컨텍스트로 다루어야 합니다.
주니어 개발자들이 혼동하는 일반적인 이유는
orientation 과 resolution 또는 context: HTML 텍스트 프래그먼트 (parent key `alternatives_cta_questions`). 페이지/영역: Capacitor live-update alternatives 비교 페이지. 역할: 장기 마케팅 또는 법률 문구. 보존: Capgo 제품/브랜드 및 개발자 용어. 메시지 키 `alternatives_cta_questions` (Alternatives CTA Questions). | HTML 텍스트 프래그먼트 (parent key `appflow_cta_questions`). 페이지/영역: Appflow 비교/이동 마케팅 복사본. 역할: 장기 마케팅 또는 법률 문구. 보존: Capgo 제품/브랜드 및 개발자 용어. 메시지 키 `appflow_cta_questions` (Appflow CTA Questions). | HTML 텍스트 프래그먼트 (parent key `capwesome_cta_questions`). 페이지/영역: Capawesome 비교 페이지. 역할: 장기 마케팅 또는 법률 문구. 보존: Capgo 제품/브랜드 및 개발자 용어. 메시지 키 `capwesome_cta_questions` (Capwesome CTA Questions). | HTML 텍스트 프래그먼트 (parent key `consulting_faq_subtitle`). 페이지/영역: 컨설팅 서비스 페이지. 역할: 섹션 서브 타이틀 또는 태그 라인. 보존: Capgo 제품/브랜드 및 개발자 용어. 메시지 키 `consulting_faq_subtitle` (Consulting FAQ Subtitle). | 페이지/영역: Appflow 비교/이동 마케팅 복사본. 역할: 짧은 UI 레이블 또는 네비게이션 아이템. 보존: Capgo 제품/브랜드 및 개발자 용어. 메시지 키 `appflow_plugins_or` (Appflow Plugins Or). aspect ratio그것들은 관련이 있지만 같은 것이 아니다.
- 방향 어느 쪽이 더 길다는 것을 의미한다.
- 해상도 어떤 픽셀들이 각 축에 존재하는지 의미한다.
- 비율 표트형태의 태블릿과 휴대폰의 표트형태는 매우 다른 크기를 가질 수 있지만 여전히 같은 방향을 공유한다. 그래서 반응형 UI 논리는 "가로가 세로보다 더 큰가?"라는 질문을 먼저 해야 한다.
표트형태 vs 가로형태의 기본 비교
이것을 생각하는 간단한 방법은 구성이다. 표트형태의 그림은 사람이나 다른 높은 주제에 집중한다. 가로형태의 그림은 너비, 맥락, 그리고 주변 공간을 캡처한다. UI도 마찬가지이다.
표트형태와 가로형태의 비교를 위한 시각적 안내서, 콘텐츠와 디바이스 디스플레이의 최적 사용을 설명한다.
In imaging and UI design, portrait orientation is the rectangle where 높이 가로보다 더 크다이러한 경우, 더 긴 변은 수직입니다. 이는 수평 방향의 반대입니다. SLR Lounge의 사전 항목 기술적 정의와 왜 이러한 모양이 세로 주제와 수직 구조에 적합한지 설명합니다.
한 표의 차이
| 방향 | 형태 | 최적 | 일반적인 효과 |
|---|---|---|---|
| 세로 | 가로보다 더 높다 | 피드, 양식, 읽기, 세로 주제 | 가로 방향은 사용자가 가로 방향으로 주의를 집중할 때 |
| 가로 | 높이보다 넓다 | 비디오, 지도, 대시보드, 넓은 장면 | 가로 방향은 더 많은 가로 방향의 맥락을 보여준다 |
그것은 기본적인 것 같지만, 제품 리뷰에서 트레이드 오프를 할 때 유용합니다.
사용자에게 변경되는 것
가로 방향은 주의를 집중하는 데 도움이 되지 않습니다. 그것은 측면 콘텐츠를 줄이고 위에서 아래로의 흐름을 encourge합니다. 그 이유로 소셜 피드, 기사 페이지, 온보딩 단계, 채팅 인터페이스는 가로 방향에서 더 깨끗하게 느껴집니다.
가로 방향은 반대입니다. 그것은 더 많은 너비를 노출시켜, 분할 뷰, 타임라인, 갤러리, 미디어 재생, 데이터가 많은 표면, 그리고 몰입형 뷰에 도움이 됩니다. 레이아웃이 측면 비교가 필요하다면, 이 가로 방향은 더 많은 호흡을 주는 경우가 많습니다.
가로 방향은 주로 맥락에 관한 것입니다.
개발자에게 변경되는 것
가장 큰 실수는 넓은 형식이 가로 방향이 아닌 포트레이트의 확장 버전이라고 생각하는 것입니다. 그것은 아니다. 정보 계층은 종종 변경되어야 합니다.
예를 들어:
- 포트레이트 모드에서, 대시보드가 카드를 단일 열로 쌓을 수 있습니다.
- 보다 넓은 모드에서, 동일한 대시보드가 여러 열로 전환하고 필터 또는 사이드 패널을 표시할 수 있습니다.
- 포트레이트 모드에서, 결제 화면은 큰 탭 대상과 단일 흐름을 우선시할 수 있습니다.
- 보다 넓은 모드에서, 동일한 화면은 field가 너무 수직으로 압축되면 불편할 수 있습니다.
모바일 레이아웃에 몰입하는 개발자들은 또한 edge handling, safe areas, 및 full-screen behavior에 대해 생각해야 합니다. 그 detalles을 조정하고 있다면 Capacitor edge-to-edge display setup 사용자가 사용 가능한 공간을 어떻게 인식하는지에 따라 orientation이 동일한 대화에 속합니다.
다양한 매체에서 일반적인 사용 사례
포트레이트 방향은 모바일 화면에서만 나타나는 것이 아니다. 그 중요성은 소프트웨어에서 시작된 개념이 아니기 때문이다.
전문가 사진 촬영은 명백한 예이다. 수직 프레임은 사람의 얼굴과 몸체를 더 잘 맞출 수 있다. fashion 사진, 책 표지, 포스터, 잡지 표지에도 같은 논리가 적용된다.
인쇄 디자인도 포트레이트 방향을 사용할 때, 좁은 열거형에서 위에서 아래로 읽을 때 좋다. 수직 프레임은 눈이 자연스럽게 페이지를 내려가게 한다.
문서와 일상적인 커뮤니케이션
대부분의 보고서, 이력서, 편지, 내부 문서는 포트레이트 방향으로 설계된다. 그 이유는 수직 페이지가 문단, 제목, 목록, 서명과 같은 읽기 순서에 잘 맞기 때문이다.
만약 PDF를 내보내고 넓은 표가 읽을 수 없게 된다면, 포트레이트 방향의 한계를 보게 될 것이다. 콘텐츠 구조에 맞는 프레임을 선택하는 것이 중요하다.
모바일 제품과 앱 흐름
이러한 상황에서 포트레이트 방향이 많은 팀의 기본적인 마음의 모델이 된다.
사용자가 반복적으로 열어보는 화면을 생각해보라:
Think about the screens users open repeatedly:
- 채팅 앱: 메시지는 세로로 쌓입니다.
- 사회 앱: 게시물, 댓글, 및 리얼은 수직 흐름으로 소비됩니다.
- retail 앱: 검색 결과 및 제품 목록은 아래로 스크롤됩니다.
- 은행 앱: 잔액, 거래, 및 확인 흐름은 일반적으로 세로 섹션으로 배열됩니다.
그것들은 우연의 일치가 아닙니다. 포트레이트는 한 손으로 사용, 손가락 스크롤, 및 선형 작업 완료를 지원합니다.
모바일 UI의 많은 부분이 직관적이게 느껴지는 이유는 인터페이스가 우측 기기를 가정하기 전에 다른 것을 가정하지 않기 때문입니다.
그것은 모든 화면이 포트레이트로 남아야 한다는 것을 의미하지 않습니다. 미디어 뷰어, 지도, 큰 차트, 및 카메라 기반 워크플로가 더 넓은 프레임에서 이익을 얻는 경우가 많습니다. 그러나 일상적인 작업 흐름에서 포트레이트는 사용자가 시작하는 곳입니다.
웹에서 방향을 처리하는 방법
웹에서 일반적인 버그는 처음에는 작아 보인다. 앱은 수평 방향으로 정렬된 뷰포트에서 깨끗하게 읽히지만, 사용자가 기기를 회전하면 차트가 넘치거나, 사이드바가 잘못된 브레이크 포인트에 나타나거나, 키보드가 제출 버튼을 가리게 되면 문제가 발생한다. 웹에서 방향은 정말 상태에 관한 것이다. 뷰포트의 모양이 바뀌었고, UI가 예측 가능한 방식으로 반응해야 한다.
개발자에게는 두 가지 작업을 분리하는 것이 중요하다. CSS는 레이아웃 변경을 처리하고, JavaScript는 동작 변경을 처리한다. 만약 이 프로젝트를 모바일용으로 패키징한다면, 여전히 이 웹层의 중요성이 있다. Capacitor을 사용하여 웹 앱을 모바일 앱으로 변환하는 것은 좋은 웹 방향 처리의 필요성을 제거하지 않는다. 이 기초가 더 중요해진다. 플랫폼은 두 가지 주요 도구를 제공한다. Screen Orientation __CAPGO_KEEP_0__은 방향 유형과 변경 이벤트를 노출하고, Web App Manifest는 설치된 앱이 선호하는 수평 방향 모드를 선언할 수 있다. 예를 들어, 또는
The platform gives you two main tools. The Screen Orientation API exposes orientation type and change events, and the Web App Manifest lets an installed app declare a preferred upright mode such as portrait, portrait-primaryCSS를 사용하여 레이아웃이 적응해야 한다. portrait-secondaryCSS부터 시작한다. 가장 저렴하고 신뢰할 수 있는 방법으로 너비와 높이가 역할을 바꾸면 반응할 수 있다. 이것은 화면 모양의 점진적 향상과 같다. 기본으로 좁은 수평 방향 레이아웃을 시작하고, 뷰포트가 더 넓어질 때만 두 번째 UI에 공간을 추가한다..
몇 가지 관행이 나중에 시간을 절약한다:
Start with CSS. It is the cheapest and most reliable way to respond when width and height swap roles.
/* Default portrait-friendly layout */
.page {
display: grid;
grid-template-columns: 1fr;
gap: 16px;
}
.sidebar {
display: none;
}
@media (orientation: landscape) {
.page {
grid-template-columns: 280px 1fr;
}
.sidebar {
display: block;
}
}This works like progressive enhancement for screen shape. Begin with the narrow, upright layout as the default. Then add room for secondary UI only when the viewport becomes wider.
A few practices save time later:
- 기본 모드에서 시작하세요: 주로 앱을 수직으로 사용하는 사람들을 위해 기본 레이아웃을 설정하세요.
- 고정된 높이를 피하세요: 장치가 회전할 때 사용 가능한 수직 공간이 빠르게 줄어들 수 있습니다. especialmente 브라우저 UI 또는 가상 키보드가 표시될 때.
- 실제 상호 작용 상태를 테스트하세요: 폼, Stickie 헤더 및 하단 시트는 회전 중에 실패하는 경우가 많습니다. 정적 스크린샷에서는 그렇지 않습니다.
JavaScript를 사용하세요:
CSS는 박스를 재배치할 수 있지만, 차트를 다시 빌드하거나 제스처 핸들러를 초기화하는 것을 결정할 수 없습니다.
JavaScript를 사용하세요:
function logOrientation() {
const type = screen.orientation?.type;
console.log('Current orientation:', type);
}
logOrientation();
screen.orientation?.addEventListener('change', () => {
logOrientation();
const isPortrait = window.innerHeight > window.innerWidth;
if (isPortrait) {
document.body.classList.remove('wide-mode');
} else {
document.body.classList.add('wide-mode');
}
});장치가 회전할 때 상태 있는 UI가 영향을 받을 때 JavaScript를 사용하세요. 회전이 레이아웃이나 배치만 변경할 때 CSS가 처리할 수 있는 경우 JavaScript를 사용하지 마세요.
이 패턴은 캔버스, 미디어 컨트롤, 지도 뷰 및 커스텀 네비게이션 셸과 같은 UI에 유용합니다. 회전이 데이터 표시 또는 상호 작용 논리를 변경할 때 JavaScript가 반응해야 합니다. 회전이 레이아웃이나 배치만 변경할 때 CSS가 처리할 수 있는 경우 JavaScript를 사용하지 마세요.
CSS가 잘 처리할 수 있는 레이아웃 결정에 JavaScript를 사용하지 마세요. junior 팀이 복잡성을 피하기 위해 사용할 수 있는 실용적인 규칙입니다.
만약 PWA가 주로 수직 사용을 위해 설계되었다면, 매니페스트에서 이를 선언하세요.
{
"name": "My App",
"short_name": "MyApp",
"display": "standalone",
"orientation": "portrait"
}이것은 선호도이며, 반응형 디자인의 대체품이 아닙니다. 브라우저가 지원하는 컨텍스트에서 설치된 앱이 어떻게 열리고 행동해야 하는지 이해하는 데 도움이 됩니다.
브라우저가 허용할 때 런타임에 오리엔테이션 잠금을 요청할 수도 있습니다:
async function lockPortrait() {
try {
await screen.orientation.lock('portrait');
console.log('Orientation locked');
} catch (err) {
console.log('Lock failed:', err);
}
}이것을 신중하게 사용하세요. 좋은 규칙은 회전이 작업 자체를 깨트릴 때만 잠금을 걸 것이며, 유도된 캡처 흐름이나 물리적 정렬 요구 사항이 있는 화면과 같은 경우입니다. 대부분의 다른 경우, 인터페이스를 적응시키는 것이 더 나은 엔지니어링 선택이기 때문에, 장치와 사용자를 모두 존중하는 것입니다.
모바일 앱의 오리엔테이션 관리
모바일 앱은 브라우저 탭보다 더 많은 것을 할 수 있습니다. 앱 수준에서 기본 화면 방향을 선언하고, 단일 화면의 동작을 변경할 때 사용할 수 있습니다. 그 추가적인 제어는 유용하지만, 팀이 회전을 너무 광범위하게 제한하는 경우, 단순한 앱이 rigidity를 느끼게 됩니다.
좋은 정신 모델이 여기서 도움이 됩니다. 앱 전체 설정은 기본 정책입니다. 화면 수준 code는 예외 layer입니다. 정책을 사용하여 광범위한 의도에 대해, 예외를 사용하여 회전하는 장치가 사용자가 완료하려고 하는 작업에 방해가 되지 않도록 합니다.
네이티브 플랫폼 제어
On Android에서 오리엔테이션은 종종 AndroidManifest.xml 활동에 대해:
<activity
android:name=".MainActivity"
android:screenOrientation="portrait" />This works like a top-level config flag. It is simple, predictable, and easy to enforce across the whole activity. The tradeoff is scope. If only one screen needs upright mode, applying that rule globally is usually too blunt.
On iOS에서 지원하는 방향은 Xcode를 통해 대상 설정과 앱 메타데이터를 통해 설정됩니다. 앱이 일반적으로 허용하는 것을 정의하고, 특정 화면이 더 엄격한 요구 사항을 가질 때 화면 컨트롤러의 동작을 세부적으로 조정할 수 있습니다.
그것은 크로스 플랫폼 팀에 중요합니다. Native config은 “이 앱은 일반적으로 허용해야 하는가?”라고 대답합니다. Runtime code은 “이 화면은 지금 무엇을 해야 하나?”라고 대답합니다.
프로그램적 제어는 Capacitor 앱에서
만약 Capacitor으로 빌드한다면, 동적 제어는 일반적으로 code에 위치해야 합니다. 그것은 화면이나 화면이 필요로 하는 경로 근처에 위치해야 합니다. 로그인 화면은 포트레이트 모드에서 더 쉽게 사용할 수 있습니다. 미디어 화면이나 카메라 흐름은 사용자가 장치를 어떻게 들고 있는지에 따라 회전을 허용해야 할 수 있습니다.
플러그인은 그 논리를 읽을 수 있게하고, 커스텀 네이티브 플러밍을 피할 수 있게합니다. __CAPGO_KEEP_0__의 __CAPGO_KEEP_1__ 앱용 화면 방향 플러그인은 Capacitor screen orientation plugin for Capacitor apps 패턴은 간단합니다. 제한을 적용할 때 화면이 활성화되면 제한을 제거할 때 화면이 더 이상 활성화되지 않습니다. 라우터 기반 앱에서, 그 일반적으로 화면 라이프 사이클 훅과 관련하여 방향 변경을 제어하는 것이 아니라, 무작위 컴포넌트에 호출을 퍼뜨리지 않습니다.
import { ScreenOrientation } from '@capgo/capacitor-screen-orientation';
async function lockLoginScreen() {
await ScreenOrientation.lock({ orientation: 'portrait' });
}
async function unlockForMedia() {
await ScreenOrientation.unlock();
}
async function checkCurrentOrientation() {
const result = await ScreenOrientation.orientation();
console.log(result);
}__CAPGO_KEEP_0__
화면에 따라 제한을 신중하게 선택하세요.
입력, 정렬 또는 사용자 초점이 방해받지 않도록 회전이 방해되지 않도록 고정된 수직 모드를 사용하세요.
일반적인 예시로는 다음과 같습니다.
- 인증 화면: 사용자가 입력하는 동안 입력이 안정적입니다.
- 결제 및 확인 단계: 고객의 주의가 집중된 작업 중 레이아웃 변경이 적습니다.
- 키오스크 또는 안내된 워크플로: 인터페이스가 일관된 하나의 표시를 필요로 합니다.
장치 방향이 변경되어도 작업을 돕는 데 도움이 되는 추가 너비 또는 다른 손잡이가 명확할 때 장치가 자유롭게 회전하세요.
미디어 재생, 지도, 게임, 카메라 뷰, 밀집된 데이터 화면과 같은 일반적인 예시로는 다음과 같습니다.
초보 팀의 유용한 규칙은 간단합니다. 장치 방향이 변경되어도 레이아웃이 변경되지 않는다면 레이아웃 시스템이 처리하도록 하세요. 장치 방향이 변경되어도 작업이 어떻게 작동하는지 변경된다면 화면 단위의 방향 code이 정당화될 수 있습니다.
Capgo는 실제로 사용되는 이유로 언급됩니다. Capacitor 프로젝트에서 방향 제어는 작은 UI 세부 사항으로 시작하여 앱 동작으로 빠르게 변하는 플랫폼 기능 중 하나입니다. 동작처럼 다루세요. 기본값을 유연하게 유지하고 제한을 가급적이면 적게, 화면이 더 이상 그 필요성을 느끼지 않을 때 제한을 제거하세요.
화면 방향에 대한 UX 최적화
화면 방향 처리는 UX 결정에서 기술 결정으로 이어집니다. code은 일반적으로 직관적입니다. 하지만 자연스럽게 느껴지는 동작을 선택하는 것이 어려운 부분입니다.
단순한 체크리스트가 도움이 됩니다:
- 주요 사용자 환경을 고려하세요: 사용자가 대부분 직립 자세로 시작한다면, 포트레이트 인터페이스의 가장 강력한 버전을 만드세요.
- 추가 너비가 가치가 있는 화면 모드에서 지원하세요: 너비가 더 필요한 화면에서는 회전을 막지 마세요.
- 명확한 이유가 있는 경우에만 잠금하세요: 폼, 결제, 보안 흐름이 잠금을 정당화할 수 있습니다. 콘텐츠 화면은 일반적으로 그렇지 않습니다.
- 회전 시 상태를 보존하세요: 사용자가 입력, 스크롤 위치, 선택된 탭을 잃지 않도록 하세요.
- 테스트를 위해 실제 기기에서 양쪽 방향성을 모두 테스트하세요: 시뮬레이터에서는 어색한 전환, 키보드 겹침 및 안전 영역 문제를 놓치게 됩니다.
더욱 광범위한 레이아웃 결정에 대해 Capacitor 앱에 대한 Capacitor UI 및 UX 지침 __CAPGO_KEEP_0__ 화면이 종종 다른 기기 크기 및 플랫폼 규약에 맞게 느껴질 때, 같은 화면이 필요하기 때문입니다.
주요 takeaway은 간단합니다. 포트레이트 방향성에 대한 질문에 대한 답은 단순히 '수직'만이 아닙니다. 그것은 프레임 규칙, 레이아웃 상태 및 사용자 예상입니다. 좋은 앱은 그것을 그대로 다룹니다.
Capacitor 앱을 배포하고 있으며, 제어된 방향성 동작과 빠른 배포 후 수정이 필요하다면 Capgo __CAPGO_KEEP_0__
