電話を回転させて画面をテストすると、レイアウトがきれいに適応したり、崩れたりします。テキストが再流れ、ボタンがジャンプし、モーダルが突然間違った場所に隠れる、または動画プレーヤーが期待どおりに動作します。その小さな瞬間は ポートレート向き デザイン用語から製品決定に変わる。
モバイル向けに開発している場合、ポートレート向きの定義に答える必要があります。 クラスルームの定義だけではなく、開発者用の定義です。レイアウトにどのように影響するか、回転をサポートするときはどのようにするか、ロックするときはどのようにするか、Webアプリ、ネイティブアプリ、__CAPGO_KEEP_0__ プロジェクトでどのように扱うか、UXが脆弱になることなく。. 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.
ポートレート向きの理解
横向き画面の理解
ユーザーは画面が回転するときに最初に気づく。開発者は回転が画面のインターフェイスを壊すときに気づく。
横向き 画面が高さが幅より大きいときを指す。基本的な考え方は、美術で人物の顔と上半身の肖像画が垂直にフレームされていたことから来ている。同様の概念は、ページデザイン、写真、デジタルインターフェイスにも広がった。参考になるより広い歴史についての情報は、 Wikipediaの画面向きの概要ビルダーにとって重要なのは、横向き画面は画面サイズ、デバイス、ファイル形式とは関係がないことである。形状に関するルールである。高さが幅より大きい場合、横向きである。 製品作業でなぜ重要か.
横向きはモバイルで実用的なデフォルトになったのは、立って使うことが自然なので、スマートフォンを横に持ちやすいからである。そうすると、スクロール、指の届きやすさ、読みやすさ、フォームの設計、ナビゲーションの配置などが変わる。
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
A feed, article view, settings screen, or chat thread は通常、垂直フレームで読みやすくなります。 その理由の 1 つは、オリエンテーション選択が直接モバイル アプリのユーザー エクスペリエンスの決定に結びつくことです。 モバイル アプリのユーザー エクスペリエンスの決定とは、単に視覚的なスタイリングとは別のものです。実用的なルール:
ポートレートをレイアウトのコンテキストとして扱うのではなく、単にデバイスの位置として扱うのではなく。 ジュニア デベロッパーが混乱するのはよくあることです。
混乱するのは、通常、
オリエンテーション を 解像度 や アスペクト レイティオ と混同することです。. これらは関連しているが、同じものではない。
- Orientation 長さのどちら側かを示す
- Resolution 各軸方向に存在するピクセルの数を示す
- Aspect ratio 幅と高さの関係を示す
端末の向きは、画面の長さと短さの関係によって決まる。
Portrait vs Landscape A Fundamental Comparison
この概念を簡単に理解する方法は、絵画の構成を考えることである。人物や高さのある主題を中心に据えた肖像画は、周囲の空間や背景を捉える横向きの絵画とは異なる。
画像やUIデザインにおいて、ポートレート向きは矩形の形をしている。 __CAPGO_KEEP_0__が__CAPGO_KEEP_1__より大きい場合、__CAPGO_KEEP_2__は垂直になります。__CAPGO_KEEP_3__は横向きの逆です。__CAPGO_KEEP_4__は__CAPGO_KEEP_5__の逆です。 SLR Loungeの用語集 __CAPGO_KEEP_6__は、技術的な定義と、__CAPGO_KEEP_7__が高さの多い主題と垂直構造に適合する理由を説明しています。
1つのテーブルの差
| 向き | 形状 | 最適 | 典型的な効果 |
|---|---|---|---|
| ポートレート | 幅より高さが高い | フィード、フォーム、読み取り、高さの多い主題 | __CAPGO_KEEP_0__は視線を垂直方向に集める |
| __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__は高さより幅が広い | __CAPGO_KEEP_0__、地図、ダッシュボード、広いシーン | __CAPGO_KEEP_0__は水平方向のコンテキストを表示する |
製品レビューの際にトレードオフをしながら作業する場合、基本的なものではあるが、実際に役立つことは多い。
ユーザーにとっての変化
__CAPGO_KEEP_0__は通常、視線を狭める。横幅の情報を減らして、上から下への流れを促す。なぜなら、__CAPGO_KEEP_0__、記事ページ、オンボーディングステップ、チャットインターフェイスは__CAPGO_KEEP_0__で綺麗に見えるからだ。
__CAPGO_KEEP_0__はその逆を起こす。横幅を広く表示することで、__CAPGO_KEEP_0__、タイムライン、ギャラリー、メディア再生、データ重視の表面、インマーシブビューなどに役立つ。レイアウトが横方向の比較を必要とする場合、この__CAPGO_KEEP_0__形式は、よりゆとりがあることが多い。
__CAPGO_KEEP_0__は通常、焦点について。__CAPGO_KEEP_0__は通常、コンテキストについて。
開発者にとっての変化
__CAPGO_KEEP_0__の最大の間違いは、__CAPGO_KEEP_0__を__CAPGO_KEEP_0__の拡張版として扱うことだ。そうではない。情報の階層が変わり得る。
例えば:
- 横向きの場合、ダッシュボードはカードを 1 つの列に積み重ねることができます。
- 横向きの場合、同じダッシュボードは、フィルターやサイドパネルを表示するために複数の列にシフトすることができます。
- 横向きの場合、決済フォームでは、大きなタップターゲットと一つの明確なフローを優先します。
- 横向きの場合、同じ画面は、フィールドが垂直方向に圧縮されすぎると不快な感じがします。
インマーシブモバイルレイアウトに取り組んでいる開発者も、エッジハンドリング、セーフエリア、フルスクリーンベHAVIORについて考える必要があります。 Capacitor edge-to-edge display setup __CAPGO_KEEP_0__ エッジレスディスプレイ設定
さまざまなメディアで共通の使用例
モバイル画面では出現しないポートレート向けの画面が、多くの場面で現れる。そうした理由は、コンセプトはソフトウェアで始まったわけではなく、ソフトウェアに限ったものでもないからだ。
写真と印刷物
プロの肖像写真は明らかな例だ。垂直枠は、広い枠ではできないように、人の顔や体を収めることができる。同様の論理は、ファッション写真、本の表紙、ポスター、雑誌の表紙にも当てはまる。
印刷物のデザインでは、読み取り体験が上から下に進むようにするために、ポートレートを使用することが多い。垂直枠は、目が自然にページの下に移動するようにするため、ページが狭い列で構成されている場合に適している。
文書と日常のコミュニケーション
ほとんどのレポート、履歴書、手紙、内部ドキュメントはポートレートで設計されている。そうした理由は、ポートレートが常に最適なものであるからではなく、垂直ページは、段落、ヘッダー、リスト、署名などのシーケンスを読む場合に適しているからだ。
PDFをエクスポートした際に、広い表が読みにくくなったことがあるだろう。そうした理由は、ポートレートの限界である。あるコンテンツは、水平形式で表現される方が適している。重要なのは、枠をコンテンツの構造に合わせることだ。
モバイル製品とアプリのフロー
このような状況では、ポートレートは多くのチームにとってデフォルトのメンタルモデルとなる。
ユーザーが繰り返し開く画面を考えれば、
- チャットアプリ: __CAPGO_KEEP_0__が垂直に積まれている。
- ソーシャルアプリ: __CAPGO_KEEP_0__、コメント、リールは通常上向きのフローで消費される。
- リテールアプリ: __CAPGO_KEEP_0__と製品リストは下方向にスクロールされる。
- 銀行アプリ: __CAPGO_KEEP_0__、取引、確認フローは通常垂直セクションに配置される。
それらのパターンは偶然ではありません。ポートレートは一手で操作、指のスクロール、線形タスクの完了をサポートしています。
モバイルUIの多くは、インターフェイスが端末を上向きに想定する前に、他の何も想定しないように設計されているため、直感的です。
すべてのスクリーンがポートレートでなければならないということではありません。メディアビューア、地図、大きなチャート、カメラベースのワークフローは、より広いフレーミングが得られることがよくあります。ただし、日常のタスクフローでは、ユーザーは通常ポートレートから始めます。
ウェブ上でオーリエンテーションを処理する
ウェブ上の一般的なバグは、最初は小さく見えます。アプリは正面のビュー ポートできれいに読み込まれますが、ユーザーが端末を回転させると、グラフがフローし、サイド バーが間違ったブレーク ポイントで表示され、キーボードが送信ボタンを隠します。ウェブ上のオリエンテーションは、実際には状態についてです。ビュー ポートの形状が変わり、UI が予測可能な方法で反応する必要があります。
開発者にとって、これは 2 つのジョブを分離することを意味します。CSS はレイアウトの変更を処理し、JavaScript は動作の変更を処理します。プロジェクトを後でモバイル向けにパッケージ化する場合、このウェブ層はまだ重要です。 Capacitor を使用してウェブアプリをモバイルアプリに変換することは ウェブ上のオリエンテーションを適切に処理する必要性を排除するものではありません。ウェブ上のオリエンテーションを適切に処理するための基盤をより重要にします。
プラットフォームは、2 つの主なツールを提供します。Screen Orientation API は、オリエンテーションタイプと変更イベントを公開し、Web App Manifest はインストール済みのアプリが、 portrait, portrait-primary、または portrait-secondaryなどの、好みの正面モードを宣言することを許可します。MDN は、そのマニフェスト値の Web App Manifest オリエンテーション リファレンスをドキュメント化しています。 CSS を使用してレイアウトが適応するようにします.
CSS で始めましょう。幅と高さが役割を入れ替える場合、最も安価で最も信頼性の高い方法で反応することができます。
これは、画面の形状に対する進化的な強化と似ています。最初は、狭い正面のレイアウトをデフォルトとして開始し、ビュー ポートが幅が広がるにつれて、セカンダリ UI にスペースを追加します。
/* 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;
}
}後で時間を節約するためのいくつかの慣習があります:
レイアウトが適応するように CSS を使用することは、画面の形状に対する進化的な強化と似ています。最初は、狭い正面のレイアウトをデフォルトとして開始し、ビュー ポートが幅が広がるにつれて、セカンダリ UI にスペースを追加します。
- __CAPGO_KEEP_0__から始めます: 主に端末を直立でアプリを使用する人々の場合、基本レイアウトをそのままにしておきましょう。
- 固定高さを避けましょう: 端末を回転させると、利用可能な垂直スペースが急激に減ります。ブラウザUIや仮想キーボードが表示されている場合も同様です。
- 実際のインタラクション状態をテストしてください: フォーム、固定ヘッダー、ボトムシートは回転中には機能しませんが、静止画では問題ありません。
JavaScriptを使用して、動作が反応する必要がある場合:
CSSはボックスを並べ替えることができますが、グラフを再構築したりジェスチャーハンドラーをリセットしたりすることはできません。
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のために、好みの向きを設定してください
__CAPGO_KEEP_0__の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な感じになることがあります。
良いメンタルモデルはここで役立ちます。アプリ全体の設定は、デフォルトのポリシーです。画面レベルのcodeは、例外層です。広い意図のためにポリシーを使用し、例外を使用するのは、回転デバイスがユーザーが試みているタスクに干渉しないようにする場合のみです。
ネイティブプラットフォームの制御
オン Android、オリエンテーションはよく、 AndroidManifest.xml 活動のために:
<activity
android:name=".MainActivity"
android:screenOrientation="portrait" />この機能は、トップレベル設定フラグとして機能します。単純、予測可能、全体的な活動に適用することが簡単です。ただし、スコープのトレードオフがあります。1つの画面のみが正面モードを必要とする場合、グローバルにルールを適用することは通常、過度に強力です。
オン iOSサポートされているオリエンテーションは、Xcodeを通じてターゲット設定とアプリメタデータで設定されます。アプリ全体でサポートされるものを定義し、特定のビュー コントローラーで厳格な要件がある画面の動作を調整することができます。
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?”
Programmatic control in Capacitor apps
If you build with Capacitor, dynamic control usually belongs in code, close to the route or view that needs it. A sign-in screen may be easier to use in portrait. A media screen or camera flow may need to allow rotation based on how the device is held.
Capacitorアプリをビルドする場合、動的制御は通常、__CAPGO_KEEP_1__に属するもので、ルートまたはビューに近い位置に配置する必要があります。サインイン画面はポートレートモードで使用しやすい場合がありますが、メディア画面またはカメラフローは、デバイスがどのように保持されているかによって回転を許可する必要があります。 Capacitor screen orientation plugin for Capacitor apps Capacitorアプリ向けの画面オリエンテーション プラグイン
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アプリ向けのクロスプラットフォームUIとUXガイドライン デバイスサイズやプラットフォームの慣習に合わせて同じ画面が自然に感じられるようにすることがよくあります。
主なポイントは簡単です。 portraitの向きを尋ねる場合、答えは単に「垂直」ではありません。
If you’re shipping Capacitor apps and need controlled orientation behavior alongside fast post-release fixes, Capgo __CAPGO_KEEP_0__アプリを配信し、制御された向きの動作と迅速なリリース後の修正が必要な場合、
