電話を回転させて画面をテストすると、レイアウトはきれいに適応するか崩れるか。テキストが再配置され、ボタンがジャンプし、モーダルが突然間違った場所に覆われ、動画プレーヤーは予想どおりに動作する。そうした小さな瞬間が ポートレート向き 設計用語から製品の決定に変わる瞬間です。
モバイル向けにアプリを開発している場合、Portraitモードの定義を明確に理解する必要があります。 目次. Not just the classroom definition, but the developer version. How it affects layout, when to support rotation, when to lock it, and how to handle it in web apps, native apps, and Capacitor projects without creating a brittle UX.
製品作業でなぜ重要か
- ジュニア開発者が混乱するポイント
- ポートレート vs ランドスケープ 基本的な比較
- さまざまなメディアで共通の使用例
- Web上でのオリエンテーション管理
- モバイルアプリのオリエンテーション管理
- 画面向きのUXベストプラクティス
ポートレート向きの理解
ユーザーは画面が回転するときに最初に向きを認識します。開発者は、回転がインターフェイスを破壊するときにそれを認識します。
ポートレート向き 画面の枠は 高さが幅より高い。 その核心はそこにある。 それは、人々の顔と上半身の肖像画が通常垂直に枠で囲まれていたことから生まれた。 その同じ概念は、ページデザイン、写真、デジタルインターフェイスに持ち込まれました。 そのより広い歴史についての良い参考資料は Wikipediaのページ向きの概要.
ビルダーにとって、重要なのは、ポートレート向きは、1つの画面サイズ、1台のデバイス、または1つのファイル形式に結びついていないことです。 それが形状に関する規則です。 高さが幅より大きい場合、ポートレートです。
製品作業でなぜ重要か
モバイル向けにポートレートが実用的デフォルトになったのは、端末を自然に持ちながら使用するためです。 それがスクロール、タップ範囲、読み取りフロー、フォームのデザイン、ナビゲーションの配置に影響します。
フィード、記事表示、設定画面、チャットのスレッドは、垂直フレームで自然に読みやすくなります。 それが、向きの選択が、ユーザー体験の決定と直接関係している理由の1つです。 モバイルアプリのユーザー体験の決定とは、単に視覚的なスタイリングとは別のものです。
実用的ルール: ポートレートをレイアウトのコンテキストとして扱うのではなく、単にデバイスの位置として扱う
ジュニア開発者が混乱するのは
混乱するのは 向き と 解像度 または 向きは、どの辺が長いのかを意味します。
- 解像度 は、各寸法に存在するピクセルの数を意味します。
- アスペクト比 は、幅と高さの関係を表します。
- 端末がポートレートモードの場合、タブレットとスマートフォンは同じ向きの状態を共有できますが、寸法は大きく異なります。 したがって、レスポンシブUIロジックは、より具体的な質問をする前に、「高さが幅より大きいかどうか」を尋ねる必要があります。 ポートレートモードとランドスケープモードの基本的な比較
解像度
または
この概念を理解する簡単な方法は、組成を通じて考えることです。肖像画は人物や他の高い対象物に焦点を当てます。水平画は幅、背景、周囲の空間を捉えます。UIも同様です。
イメージングとUIデザインでは、肖像画の場合、 高さが幅を超える、つまり、長い辺が垂直です。水平画の逆です。 SLR Loungeの用語解説 はその技術的な定義と、その形状が高い対象物や垂直構造に適している理由を説明しています。
差異を一目でわかる表
| 向き | 形状 | 最適なフィット | コンテキスト: Capgo Builder / ネイティブクラウドビルド製品ページ。役割: 短いUIラベルまたはナビゲーションアイテム。メッセージキー `native_build_builder_compare_fit_feature` (ネイティブビルドビルダー比較フィット機能)。 |
|---|---|---|---|
| Portrait | 幅が高さより大きい | フィード、フォーム、読み物、高い主題 | 視線を垂直方向に集中させる |
| ランドスケープ | 幅が高さより大きい | 動画、地図、ダッシュボード、広いシーン | 水平方向のコンテキストを表示する |
それだけのことは簡単ですが、製品レビューのトレードオフの際に役立ちます。
ユーザーにとっての変化
ポートレートは視線を狭める。側面のコンテンツを減らし、上から下へのフローを促す。なぜなら、ソーシャルフィード、記事ページ、オンボーディングステップ、チャットインターフェイスはポートレートで綺麗に感じられるからです。
水平方向はその逆です。幅を広く表示し、スプリットビュー、タイムライン、ギャラリー、メディア再生、データ重視の表面、インマーシブビューに役立ちます。レイアウトが横方向の比較が必要な場合、この水平形式はよりゆとりがあります。
ポートレートは通常、焦点についてです。ランドスケープは通常、背景についてです。
開発者にとって何が変わりますか
最大の間違いは、幅の広い形式をポートレートの伸縮版として扱うことです。それではありません。情報の階層がしばしば変わります。
例えば
- ポートレートでは、ダッシュボードはカードを単一の列に積み重ねることができます。
- 幅の広いオリエンテーションでは、同じダッシュボードは複数の列にシフトし、フィルターやサイドパネルを表示することができます。
- ポートレートでは、決済フォームでは、大きなタップターゲットと一つの明確なフローを優先します。
- 幅の広いオリエンテーションでは、同じ画面は、フィールドが垂直方向に圧縮されすぎると不快な感覚を与えることができます。
開発者が、インmersiveモバイルレイアウトを開発する際には、エッジハンドリング、セーフエリア、フルスクリーンベハビアについて考える必要があります。調整する詳細を調整している場合、__CAPGO_KEEP_0__ エッジトゥエッジディスプレイ設定は同じ会話の一部です。 Capacitor エッジからエッジまでのディスプレイ設定 さまざまなメディアで共通の使用例
メディアをまたがる一般的な用途
スマートフォンを使用してソーシャルメディアのコンテンツをスクロールする人の近くから見た写真。
プロのポートレート写真は明らかな例です。垂直フレームは人面と身体を収めるのに広いフレームよりも適しています。同様の論理は、ファッション写真、ブックカバー、ポスター、雑誌カバーにも当てはまります。
印刷物のデザインでは、読み取り体験が上から下に進むようにするために、ポートレートを使用します。垂直フレームは、目が自然にページを下に移動するように助けます。
文書と日常のコミュニケーション
日常文書と一般的なコミュニケーション
PDFをエクスポートしたことがある場合は、広いテーブルが読み取り不可能になったことがあるかもしれません。そうである理由は、ポートレートも限界があります。コンテンツ構造に合ったフレームを選択することが重要です。
コンテンツの構造に合ったフレームを選択することが重要です。
モバイル製品とアプリのフロー
状況はこうなっているため、多くのチームではポートレートがデフォルトのメンタルモデルになります。
ユーザーが繰り返し開く画面を考えてみましょう:
- チャットアプリ: メッセージは垂直に積み重ねられます。
- ソーシャルアプリ: 投稿、コメント、リールは上向きのフローで消費されます。
- リテールアプリ: 検索結果と製品リストは下方向にスクロールします。
- 銀行アプリ: 残高、取引、確認フローは通常、垂直セクションで配置されます。
それらのパターンは偶然ではありません。ポートレートは片手での使用、指のスクロール、線形タスクの完了をサポートしています。
モバイルUIは、端末が真横になる前には、他の何もを前提とせずに、インターフェイスが端末を真横に想定していることが多いので、多くのモバイルUIは直感的に感じられる。
端末の向きを考慮せずにUIを作ることは、多くの場合、ユーザーに直感的な体験を提供するため、簡単に思えるかもしれません。
That doesn’t mean every screen should stay portrait. Media viewers, maps, large charts, and camera-based workflows often benefit from wider framing. But for everyday task flow, portrait is usually where users begin.
端末の向きを考慮しないUIは、日常のタスクフローでは、ユーザーにとっては通常の状態ではありません。
Handling Orientation on the Web ウェブアプリをモバイルアプリに変えるには、Capacitorを使用します。 ウェブの向きの扱いには、良いものが必要です。向きの扱いを良くするための基盤は、より重要になります。
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-primary, or portrait-secondary開発者にとっては、2つのタスクを分離する必要があります。CSSはレイアウトの変更を、JavaScriptは動作の変更を扱います。 ウェブアプリマニフェストのオリエンテーションリファレンス.
ウェブアプリをモバイルアプリに変換するには、__CAPGO_KEEP_0__を使用します。
CSSから始めましょう。幅と高さが役を交換するときに最も安価で信頼性の高い方法です。
/* 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;
}
}画面の形状に対応するように進化的な強化が働くように動作します。最初は窄い立ち上がったレイアウトをデフォルトとして開始し、ビューが広くなったときにのみセカンダリUIにスペースを追加してください。
いくつかの実践は後で時間を節約することができます。
- 基本モードから始めましょう: 主にアプリを立ち上がった状態で利用する人々が多い場合、そのベースレイアウトを設定してください。
- 固定高さを避けましょう: デバイスを回転すると、ブラウザUIや仮想キーボードが表示されているときに利用可能な垂直スペースが早く縮小します。
- 実際のインタラクション状態をテストしてください: フォーム、スティッキーヘッダー、ボトムシートは回転中に失敗することがよくありますが、静的スクリーンショットではありません。
JavaScriptを使用する必要があるときは、JavaScriptを使用してください。
CSSは箱を並べ替えることができますが、グラフを再構築したりジェスチャーハンドラーをリセットしたりすることはできません。
JavaScriptを使用する必要があるときは、JavaScriptを使用してください。画面の向きがUIの状態を影響する場合
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');
}
});そのパターンは、キャンバス、メディアコントロール、地図ビュー、カスタムナビゲーションシェルなどに役立ちます。 メンタルモデルは単純です。 回転がデータの表示またはインタラクションロジックを変更する場合、JavaScriptは対応する必要があります。 回転がスペースまたは配置のみを変更する場合、CSSがそれを処理するようにします。
ジュニアチームが複雑さを避けるために役立つ実用的なルールがあります。 CSSがすでにうまく処理しているレイアウトの決定をJavaScriptで強制しないでください。
PWAsの向きを設定する
PWAが主に直立で設計されている場合、manifestでそれを宣言してください。
{
"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);
}
}これを慎重に使用してください。 良いルールは、回転がタスク自体を破壊する場合にのみロックすることです。 例えば、ガイド付きキャプチャフローまたは物理的な配置要件が厳密なスクリーンなどです。 ほとんどの場合、インターフェイスを適応させる方が良いエンジニアリングの選択肢です。 それは、デバイスとユーザーを尊重するからです。
モバイルアプリの向きの管理
モバイルアプリはブラウザタブよりも多くのことができます。 アプリレベルでデフォルトの画面方向を宣言し、タスクがそれを要求する場合にのみ、単一の画面の動作を変更することができます。 その追加の制御は役立ちますが、チームが回転を広く制限することで、単純なアプリがrigidな感じになるという共通の間違いを生み出します。
A good mental model helps here. App-wide settings are your default policy. Screen-level code is the exception layer. Use the policy for broad intent, and use the exception only where a rotating device would interfere with the job the user is trying to finish.
ネイティブプラットフォームコントロール
On AndroidAndroid AndroidManifest.xml 活動の場合：
<activity
android:name=".MainActivity"
android:screenOrientation="portrait" />for an activity:
On iOSiOS
That split matters for cross-platform teams. Native config answers, “What should this app generally allow?” Runtime code answers, “What should this screen do right now?”
プログラムによる制御はCapacitorアプリ内で行うことができます。
あなたが Capacitor でビルドする場合、動的コントロールは通常 code にあるべきです。近いルートまたはビューに近いです。サインイン画面はポータレートモードで使いやすいかもしれません。メディア画面やカメラフローは、デバイスの持ち方に応じて回転を許可する必要があります。
プラグインはそのロジックを読みやすく、カスタムネイティブのパイプラインを避けることができます。 Capacitor の Capacitor アプリ用の画面向きプラグイン __CAPGO_KEEP_0__ 画面向きプラグインは、現在の向きを読み取ることができ、特定のモード（ポータレートなど）で制限を適用し、ユーザーがフリックスクリーンに戻ると制限を削除することができます。
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);
}パターンは簡単です。画面がアクティブになったときに制限を適用し、画面がアクティブではないときに制限を削除します。ルーターベースのアプリでは、向きの変更をページライフサイクルハックに結びつけることが多く、ランダムなコンポーネントに散らばった呼び出しを避けることができます。
画面向きの制限を慎重に選択してください
回転が入力、配置、またはユーザーフォーカスを混乱させる場合、固定の直立モードを選択してください。
一般的な例としては次のとおりです。
- 認証画面: ユーザーが入力を入力するときに、入力が安定します。
- 決済と確認のステップ: 高注意力タスク中のレイアウトの変更が少なくなります。
- キオスクまたはガイドドワークフロー: インターフェイスは、一貫したプレゼンテーションが必要です。
デバイスを自由に回転させて、余分な幅や異なるグリップがタスクを助ける場合に、追加の幅が必要な場合や異なるグリップが必要な場合にのみ、デバイスを回転させてください。
メディア再生、地図、ゲーム、カメラビュー、密集したデータスクリーンなど、典型的な例があります。
ジュニアチームにとって便利なルールは単純です。デバイスの方向を変更するとスペースが変化する場合、レイアウトシステムがそれを処理するようにしてください。デバイスの方向を変更するとタスクが変化する場合、スクリーンレベルのオリエンテーションcodeが正当化される場合があります。
Capgoはここで実用的な理由で言及されています。Capacitorプロジェクトでは、オリエンテーション制御は小さなUI詳細から始まり、すぐにアプリの動作になります。動作と同じように扱ってください。デフォルトは柔軟に保ち、制限を慎重に適用し、スクリーンがそれらを必要としなくなったら削除してください。
スクリーンオリエンテーションのUXベストプラクティス
オリエンテーション管理はUXの決定から始まり、技術的な決定が2番目です。codeは通常は簡単です。難しいのは、自然な動作を選択することです。
短いチェックリストが役立ちます。
- 主なコンテキストに設計してください。 ほとんどのユーザーが直立で始まる場合、ポートレートが最も強力なインターフェイスであることを確認してください。
- より広い表示モードをサポートしてください。 回転をブロックしないでください。横幅が増える画面では。
- ロックするには明確な理由があります: フォーム、チェックアウト、またはセキュアフローはそれを正当化するかもしれません。コンテンツ画面はそうではありません。
- 回転中に状態を保存してください: ユーザーは入力、スクロール位置、または選択されたタブを失うことはありません。
- 実機で両方の向きをテストしてください: シミュレータでは不快なトランジション、キーボードの重なり、セーフエリアの問題が見つかりません。
より広いレイアウトの決定については クロスプラットフォームのUIとUXガイドラインはCapacitorアプリに適しています。 向きのテストは、同じ画面が異なるデバイスサイズとプラットフォームの慣習に適応する必要があるため、向きのテストとよく相性が良いです。
主なポイントは簡単です。Portrait Orientationとは単に「垂直」だけではありません。フレーミングのルール、レイアウトの状態、ユーザーの期待です。良いアプリはそれをそうと考えています。
Capacitorアプリを配信し、制御された向きの動作と迅速なリリース後の修正が必要な場合は Capgo CapacitorJSとElectronアプリ向けのライブアップデートを提供し、画面の向きを制御する機能など、特定のビューをロックまたは有効にする機能を提供するプラグインも維持しています。
