開発デスクトップは、必要な 1 つの情報を隠しているため、忙しそうに見えることがあります。エディター、プレビュー、ターミナル、ドキュメント、および問題トラッカーはすべて関連していますが、常に同じように関連しているわけではありません。
他の人のセットアップに似ているという理由でレイアウトを選択するのではなく、最初から最後まで 1 つの通常の変更を追跡します。そのループの最適な配置は、使用するすべてのツールの永続的なグリッドよりも便利な開始点です。
要点
編集、実行、検査のループを中心にウィンドウを配置します。編集者に十分な余地を与え、結果を近くに保ち、特定の質問に回答するときにドキュメントやログを表示します。
1 つの小さな開発サイクルをマッピングする
通常の変更を行います。フォームを調整したり、失敗したテストを修正したり、データ変換を検査したりします。編集する場所、実行方法、結果を検査する場所を書き留めます。これらは便利な位置にあるべき作業面です。
ブラウザベースのインターフェイスの場合、ループはエディタ、端末、ブラウザになります。コマンドライン ツールの場合は、ドキュメントが近くにあるエディターとターミナルの場合があります。ネイティブ アプリの場合、結果は実行中のアプリまたはシミュレーターになる可能性があります。単一の所定の配置では、これらすべてを均等に適合させることはできません。
必要な作業を保存した後でのみ、無関係なプロジェクト ウィンドウを閉じてください。アクティブなタスクを認識可能なウィンドウのセットのままにしておき、ツールを追加する前にレイアウトが役に立っているかどうかを判断できます。
エディターにコンテンツベースの幅を与える
実際に必要なコードとパネルに合わせてエディターのサイズを調整します。ファイル ツリー、2 番目のエディタ ペイン、および診断サイドバーはすべて、コードが開始される前にスペースを消費します。中央ファイルが読みにくくなった場合は、不要なパネルを削除するか、ウィンドウを広げてください。
スクロール レイアウトでは、ストリップに追加のウィンドウを追加しながら、選択した幅を維持できます。 Glidro では、サイズ変更プリセットにより、繰り返しのサイズを簡単に再確認できるようになります。考えられるすべての配置を予想しようとするのではなく、小さな有用な範囲を選択してください。
すべてのツールが収まるまでテキストを縮小してウィンドウ幅の問題を解決しないでください。テキストの検査が難しい場合は、目に見える密度がコストとなります。編集をサポートする幅を維持し、必要に応じてサポート ウィンドウに移動します。
結果を検査する場所に置きます
エディターを頻繁に比較する場合は、プレビューをエディターの横に置きます。両方を同時に表示する必要がある場合は、幅を組み合わせたときに有用なコンテンツが表示されることを確認してください。プレビューに広いビューポートが必要な場合は、誤解を招く狭い比較を強制するのではなく、完全な作業ビューを交互に切り替えます。
ブラウザ ウィンドウの幅は Web インターフェイス テストの一部であるため、何を観察しているかを明確にしてください。デスクトップ レイアウトによって狭くなったプレビューは、意図的な応答性テストの代わりにはなりません。 「結果を確認できますか?」という質問は分けてください。 「正しいビューポートをテストしましたか?」から
2 番目のディスプレイの場合は、継続的な表示が役立つ場合に使用します。ドッキング解除によってワークフローの理解が損なわれないように、同じプロジェクトに対してラップトップのみのフォールバックを維持します。
ターミナルとログの役割を決める
現在のコマンドに使用されている端末をエディターまたは結果の近くに置いてください。アプリがサポートしている場合は、ターミナル独自の機能を通じてセッションにラベルを付けるか区別します。視覚的に似たシェルが並んでいると、目的地が曖昧なままになるため、空間ナビゲーションの有用性が低くなります。
ログを前に進めて質問に答えてから、コードに戻ります。再生中に出力を継続的に監視する必要がある場合は、そのフェーズ用の可視スペースを与えてください。すべてのバックグラウンド プロセスが永続的に表示されるウィンドウに値するとは考えないでください。
エディターに統合されたターミナルと別個のウィンドウのどちらがこのプロジェクトに適しているかを決定します。マネージャーはウィンドウを制御しますが、すべての内部エディター ペインを制御するわけではありません。エディター内のコンテンツにはエディター独自のナビゲーションを使用し、アプリ間の遷移にはウィンドウ コントロールを使用します。
プロジェクトのコンテキストとショートカットの所有権を保護する
ブラウザ ウィンドウとターミナルが混同しやすい場合は、無関係なプロジェクトを分離します。タスク境界は、どのリポジトリ、プレビュー、ノートが一緒に属しているかを認識するのに役立ちます。結果としてコマンドを発行する前に、ツール自体を使用して作業ディレクトリとターゲット環境を確認してください。
エディターやターミナルで使うキーと、ウィンドウ操作のショートカットが重なっていないか確認します。単語の移動、コマンド実行、エディター内の移動に使うキーで、意図せずウィンドウ配置が変わるのは避けたいところです。実際に使うアプリを前面にしてショートカットを試し、競合したらどちらか一方の割り当てを変更します。
Glidro は、編集可能なショートカットとアプリの組み込みコントロールを提供します。所有している開発ツールに合わせてこれらを使用し、特別なウィンドウで通常の処理が必要な場合は単純な一時停止ルートを保持します。既存の MacBook コーディング セットアップ ガイド は、ラップトップに焦点を当てた補完的なウォークスルーを提供します。
よくある質問
ターミナルは常に表示されたままにしておく必要がありますか?
継続的な出力が重要な場合のみ。多くのタスクでは、近くに置いて集中しやすくするだけで十分です。
ウィンドウマネージャーはエディターペインを配置できますか?
ウィンドウ管理はウィンドウ レベルで動作します。タブ、内部ペイン、統合ターミナルにはエディター独自のコントロールを使用します。
