akira/keinasystem

Fork 0

Files

akira 8de27de335 第2版

2026-04-07 10:33:29 +09:00

13 KiB

Raw Blame History

ナビゲーション再編仕様書

作成日: 2026-04-07 対象: frontend/src/components/Navbar.tsx 方針: 第一候補「上段5分類 + ドロップダウン」

0. 背景

現状のグローバルナビゲーションは、機能追加のたびに横並びのボタンを増やしており、以下の問題が出ている。

上位階層の導線が多すぎて、目的の画面を探しにくい
「計画」「実績」「設定」「補助機能」が同じ粒度で並んでいる
メール関連のように、単独トップに置くほどではない機能が場所を取りやすい
今後も機能追加が続くと、横幅不足と認知負荷の両方が悪化する

このため、トップナビは「日常的に使う業務カテゴリ」だけを見せ、個別画面はドロップダウン配下へ整理する。

1. 目的

1-1. 目指す状態

1階層目では「何をしたいか」で探せる
似た役割の画面を同じカテゴリに集約する
画面数が増えても、トップレベルの見た目を増やしすぎない
PC とスマホで同じ情報設計を維持する

1-2. 今回の対象

共通ヘッダー内のグローバルナビゲーション再編
メニュー分類、ラベル、並び順、開閉仕様の定義
各画面がどのカテゴリに属するかの明確化

1-3. 今回やらないこと

各業務画面そのものの UI 改修
権限別メニュー出し分け
お気に入り機能、ピン留め機能
ナビゲーションと連動したダッシュボード内容の刷新

2. 基本方針

2-1. トップレベル構成

トップナビでは以下の 5 項目のみを常時表示する。

ホーム
計画
実績
資材・帳票
その他

右端には従来どおりユーザー操作を置く。

パスワード変更
ログアウト

2-2. 設計ルール

毎日使う業務カテゴリだけをトップに置く
個別機能名ではなく、業務単位で束ねる
設定、履歴、通知、補助系は単独トップにしない
同じ業務の前後工程は可能な限り同じカテゴリに寄せる

3. 情報設計

3-1. カテゴリ構成

ホーム

ダッシュボード

計画

作付け計画
施肥計画
田植え計画
運搬計画

実績

散布実績
畔塗記録
作業記録

資材・帳票

圃場管理
在庫管理
帳票出力
データ取込

その他

気象
メール
設定

3-2. メールの扱い

メール関連はトップ階層に個別表示しない。 その他 > メール の中にまとめる。

内訳:

メール履歴
メールルール

3-3. 設定の扱い

現状はパスワード変更のみだが、将来の設定追加を見越して その他 > 設定 という置き方を前提にする。ただし初期実装では、右上アイコンからのパスワード変更導線は維持してよい。

4. 画面とメニューの対応

4-1. 現在の主要画面の所属

カテゴリ	ラベル	パス
ホーム	ダッシュボード	`/dashboard`
計画	作付け計画	`/allocation`
計画	施肥計画	`/fertilizer`
計画	田植え計画	`/rice-transplant`
計画	運搬計画	`/distribution`
実績	散布実績	`/fertilizer/spreading`
実績	畔塗記録	`/levee-work`
実績	作業記録	`/workrecords`
資材・帳票	圃場管理	`/fields`
資材・帳票	在庫管理	`/materials`
資材・帳票	帳票出力	`/reports`
資材・帳票	データ取込	`/import`
その他	気象	`/weather`
その他 > メール	メール履歴	`/mail/history`
その他 > メール	メールルール	`/mail/rules`
その他 > 設定	パスワード変更	`/settings/password`

4-2. アクティブ表示ルール

その画面自身、またはその配下詳細画面にいる場合、所属カテゴリをアクティブにする
ドロップダウン内の該当項目も個別にアクティブ表示する
パス接頭辞だけで判定するとカテゴリが衝突する画面があるため、より具体的なパスを優先して判定する
特に 施肥計画 と 散布実績 はともに /fertilizer 配下を使うため、/fertilizer/spreading を先に判定し、計画 側から明示的に除外する
例:
- /fertilizer は 計画 をアクティブ
- /fertilizer/new は 計画 をアクティブ
- /fertilizer/[id] および /fertilizer/[id]/edit は 計画 をアクティブ
- /fertilizer/spreading は 実績 をアクティブ
- /fertilizer/spreading?... も 実績 をアクティブ
例:
- /fields/123 の場合は 資材・帳票 がアクティブ
- /fertilizer/10/edit の場合は 計画 がアクティブ
- /mail/history の場合は その他 と メール履歴 がアクティブ

5. PC 表示仕様

5-1. レイアウト

PC ではヘッダーを 3 ブロック構成とする。

左: ブランド名 KeinaSystem
中央: トップメニュー 5 項目
右: パスワード変更、ログアウト

5-2. トップメニューの見せ方

ホーム は単独リンク
計画 実績 資材・帳票 その他 はドロップダウン付きメニュー
ラベルの横に開閉アイコンを表示する
開いたメニューは白背景のパネルとして表示する

5-3. 開閉ルール

クリックで開閉
開いている他メニューがある場合は、それを閉じてから新しいメニューを開く
メニュー外クリックで閉じる
Esc キーで閉じる
項目クリック後は遷移して閉じる

5-4. ドロップダウンの表示内容

各項目は以下の順で並べる。

計画

作付け計画
施肥計画
田植え計画
運搬計画

実績

散布実績
畔塗記録
作業記録

資材・帳票

圃場管理
在庫管理
帳票出力
データ取込

その他

気象
メール
設定

メール と 設定 は 2 段構造にする方法と、直接展開せず一覧モーダル風に見せる方法があるが、初期実装ではシンプルさを優先し、その他 ドロップダウン内に個別リンクを直接置く。

初期実装の並び:

気象
メール履歴
メールルール
パスワード変更

なお情報設計上の名称としては メール 設定 を維持し、将来的に機能が増えた時点で再度サブグループ化する。

6. スマホ表示仕様

6-1. 基本方針

スマホではハンバーガーメニューを採用する。 PC と同じカテゴリ構成を維持し、見た目だけ縦並びにする。

6-2. 表示ルール

初期状態ではロゴ、メニューボタン、ログアウト系導線のみ表示
メニューボタン押下で全画面または右スライドのメニューを開く
カテゴリはアコーディオン形式で開閉する

6-3. 並び順

ホーム
計画
実績
資材・帳票
その他
パスワード変更
ログアウト

6-4. 開閉ルール

カテゴリ見出しタップで開閉
現在表示中の画面が属するカテゴリは初期状態で展開してよい
項目タップ後はメニューを閉じて画面遷移する

7. ラベル方針

7-1. トップ階層ラベル

短く、役割が伝わる言葉を使う
詳細機能名は 2 階層目へ寄せる

7-2. 用語ルール

ホーム は利用者に最も分かりやすいため維持
計画 は作付け、施肥、田植え、運搬を含む包括名として使用
実績 は記録系業務のまとめ先とする
資材・帳票 はやや広いが、現状機能数とのバランスを優先
その他 は補助機能置き場として扱う

将来 その他 に機能が増えすぎた場合は、次の再編を検討する。

連携
設定
通知

8. アイコン方針

8-1. トップ階層

トップ階層には必要最低限のアイコンのみ使用する。

ホーム: 家またはダッシュボード系
計画: 作物または計画系
実績: チェック、記録系
資材・帳票: 箱またはファイル系
その他: 省略記号または設定系

ただし、文字認識を優先し、アイコンは補助扱いとする。

8-2. ドロップダウン内

現行アイコンを流用してよいが、すべてに付ける必要はない。視認性よりも一覧性を優先し、テキスト中心でも可。

9. 操作性・アクセシビリティ要件

キーボードでトップメニューにフォーカス移動できること
Enter または Space でドロップダウンを開閉できること
Esc で閉じられること
現在位置が視覚的に分かること
タップ領域は十分に確保すること
スマホで誤タップしにくい行間と余白を確保すること

10. 実装方針

10-1. コンポーネント構成案

Navbar.tsx を以下の責務に分ける。

ブランド表示
トップメニュー定義
ドロップダウン表示
モバイルメニュー表示
右端ユーザー操作

必要に応じて次のような補助構成へ分割してよい。

navGroups 定数
DesktopNav
MobileNav

10-2. メニュー定義データ化

個別ボタンの直書きはやめ、カテゴリ配列で管理する。

想定イメージ:

const navGroups = [
  {
    key: 'home',
    label: 'ホーム',
    type: 'link',
    href: '/dashboard',
  },
  {
    key: 'planning',
    label: '計画',
    type: 'group',
    items: [
      { label: '作付け計画', href: '/allocation' },
      { label: '施肥計画', href: '/fertilizer' },
      { label: '田植え計画', href: '/rice-transplant' },
      { label: '運搬計画', href: '/distribution' },
    ],
  },
];

10-3. アクティブ判定

アクティブ判定は、現在の pathname と各項目の対応パターンで管理する。

例:

/fertilizer
/fertilizer/new
/fertilizer/[id]/edit

はすべて 施肥計画 所属として扱う。

11. 段階導入案

Phase 1

PC ナビを 5 分類へ再編
その他 は単純なリンク群として実装
モバイルも同じ情報設計へ変更

Phase 2

その他 内を メール 設定 にサブグループ化
よく使う画面の履歴や最近使った機能を補助表示

Phase 3

将来マルチユーザー化した場合の再設計検討
権限や担当業務ごとの表示最適化の要否整理
単独利用を前提とする間は、Phase 3 は実施対象外とする

12. 受け入れ条件

トップレベルに常時表示される業務メニューが 5 項目に収まっていること
現在存在する主要画面が、いずれかのカテゴリに漏れなく所属していること
各画面でアクティブ状態が期待通りに表示されること
PC とスマホで同じカテゴリ構成になっていること
メニューが増えても、トップレベルの項目数を増やさずに拡張できること

13. 想定される懸念と対応

13-1. 「資材・帳票」が少し広すぎる

現時点では機能数のバランスを優先し、この分類を採用する。今後、帳票やマスタ管理が増えた場合は 資材 と 帳票・管理 に再分割する。

補足:

圃場管理 は本来、圃場マスタとして独立性の高い機能であり、資材 と完全に同質ではない
ただし現時点では、単独トップにするほどの件数ではなく、資材・帳票 にまとめるのが最も全体バランスが良い
将来、圃場関連の設定や地図系機能が増えた場合は、圃場・マスタ のような独立カテゴリ化を再検討する

13-2. 「その他」が曖昧

現時点では補助機能数が少ないため許容する。メール、設定、外部連携系が増えた段階で再分割を検討する。

13-3. 「データ取込」は日常操作ではない

データ取込 は日常的に何度も使う画面ではなく、年度切替時や初期設定時に使う補助導線である。そのためトップレベル常設には置かず、資材・帳票 配下に置く判断は妥当とする。

ただし今後、取込対象や運用頻度が増えた場合は、設定 または 運用 系カテゴリへの移設も検討対象とする。

13-4. 既存ユーザーが場所を見失う

初期導入時は以下を行う。

並び順をできるだけ業務の流れに合わせる
ドロップダウン内で既存画面名は変更しない
ダッシュボード上に主要導線を残す

14. 結論

現行の 1 画面 1 ボタン方式は、今後の機能追加に対して拡張性が低い。そのため、トップナビは ホーム / 計画 / 実績 / 資材・帳票 / その他 の 5 分類へ再編し、個別画面はドロップダウン配下に置く。

この構成により、利用者は「画面名」ではなく「やりたい業務」から機能を探せるようになり、将来の機能追加にも耐えやすくなる。

13 KiB Raw Blame History

ナビゲーション再編仕様書

0. 背景

1. 目的

1-1. 目指す状態

1-2. 今回の対象

1-3. 今回やらないこと

2. 基本方針

2-1. トップレベル構成

2-2. 設計ルール

3. 情報設計

3-1. カテゴリ構成

ホーム

計画

実績

資材・帳票

その他

3-2. メールの扱い

3-3. 設定の扱い

4. 画面とメニューの対応

4-1. 現在の主要画面の所属

4-2. アクティブ表示ルール

5. PC 表示仕様

5-1. レイアウト

5-2. トップメニューの見せ方

5-3. 開閉ルール

5-4. ドロップダウンの表示内容

計画

実績

資材・帳票

その他

6. スマホ表示仕様

6-1. 基本方針

6-2. 表示ルール

6-3. 並び順

6-4. 開閉ルール

7. ラベル方針

7-1. トップ階層ラベル

7-2. 用語ルール

8. アイコン方針

8-1. トップ階層

8-2. ドロップダウン内

9. 操作性・アクセシビリティ要件

10. 実装方針

10-1. コンポーネント構成案

10-2. メニュー定義データ化

10-3. アクティブ判定

11. 段階導入案

Phase 1

Phase 2

Phase 3

12. 受け入れ条件

13. 想定される懸念と対応

13-1. 「資材・帳票」が少し広すぎる

13-2. 「その他」が曖昧

13-3. 「データ取込」は日常操作ではない

13-4. 既存ユーザーが場所を見失う

14. 結論

13 KiB

Raw Blame History