マスタードキュメント化しました。追加したのは 17_マスタードキュメント_ナビゲーション再編編.md です。
内容は、今回の仕様案をそのまま移すだけでなく、 なぜこの再編が必要になったか なぜ マスター / 帳票・連携 という分類にしたか URL とメニューをどう切り分けるか Phase 1〜3 をどう進めるか まで、長期参照向けに整理してあります。 改善案/ナビゲーション再編仕様書.md は実装向け詳細、今回追加したマスタードキュメントは長期保管用、Issue #13 は議論の背景、という役割分担にしています。必要なら次に、既存のどこかからこの 17_...md へ参照リンクを足します。
This commit is contained in:
akira
298
document/17_マスタードキュメント_ナビゲーション再編編.md
Normal file
298
document/17_マスタードキュメント_ナビゲーション再編編.md
Normal file
@@ -0,0 +1,298 @@
|
||||
# マスタードキュメント：ナビゲーション再編
|
||||
|
||||
> **作成**: 2026-04-07
|
||||
> **最終更新**: 2026-04-07
|
||||
> **対象機能**: グローバルナビゲーション再編（トップメニュー整理・カテゴリ再編・PC/スマホ共通情報設計）
|
||||
> **実装状況**: 仕様策定完了・未実装
|
||||
|
||||
---
|
||||
|
||||
## 概要
|
||||
|
||||
機能追加に伴って共通ナビゲーションのトップレベル項目が増え、画面名ベースで並ぶ構造になってきたため、業務カテゴリ単位で再整理する。
|
||||
|
||||
今回の再編では、トップナビを `ホーム / 計画 / 実績 / マスター / 帳票・連携` の 5 分類に絞り、個別画面はドロップダウン配下に集約する。
|
||||
これにより、利用者が「どの画面名か」ではなく「何をしたいか」で画面を探せる状態を目指す。
|
||||
|
||||
また、URL 構造とメニュー構成は意図的に分離して扱う。既存 URL は安定性を優先して原則維持し、アクティブ判定はナビ定義側で吸収する。
|
||||
|
||||
### 機能スコープ（IN / OUT）
|
||||
|
||||
| IN（今回対象） | OUT（今回対象外） |
|
||||
|---|---|
|
||||
| PC ヘッダーのトップメニュー再編 | 各業務画面自体のUI改修 |
|
||||
| スマホ用ハンバーガーメニュー再編 | 権限別メニュー出し分け |
|
||||
| メニュー分類、並び順、開閉仕様 | お気に入り、ピン留め |
|
||||
| アクティブ判定ルール整理 | ダッシュボード内容の刷新 |
|
||||
| `NavGroup` / `NavItem` ベースのメニュー定義整理 | URL の全面変更 |
|
||||
| `作物` `品種` を将来のマスター画面として位置づけ | 矢印キー移動を含む高度なメニューアクセシビリティ |
|
||||
|
||||
---
|
||||
|
||||
## 背景と判断理由
|
||||
|
||||
### 現状の課題
|
||||
|
||||
- 横並びのトップメニュー数が多く、目的の画面を探しにくい
|
||||
- `計画` `実績` `設定` `補助機能` が同じ粒度で並んでいる
|
||||
- 画面名ベースで項目が増えており、業務単位でまとまっていない
|
||||
- 今後も機能追加が続くと、視認性と拡張性の両方が悪化する
|
||||
|
||||
### 採用した考え方
|
||||
|
||||
1. トップレベルは日常的に使う業務カテゴリだけに絞る
|
||||
2. 個別機能名ではなく、業務単位で束ねる
|
||||
3. URL はリソース識別子として安定性を優先し、メニュー構成とは分離する
|
||||
4. 例外的な URL 衝突のみナビ定義側のルールで吸収する
|
||||
|
||||
### 関連議論
|
||||
|
||||
- 判断理由、論点の切り分け、URL とメニューの関係整理は Gitea Issue `#13` に残す
|
||||
- 実装向けの決定事項は `改善案/ナビゲーション再編仕様書.md` に集約する
|
||||
- 本ドキュメントは、その内容を長期参照用に固定化したものとして扱う
|
||||
|
||||
---
|
||||
|
||||
## 情報設計
|
||||
|
||||
### トップレベル構成
|
||||
|
||||
1. ホーム
|
||||
2. 計画
|
||||
3. 実績
|
||||
4. マスター
|
||||
5. 帳票・連携
|
||||
|
||||
右上ユーザー操作:
|
||||
|
||||
- パスワード変更
|
||||
- ログアウト
|
||||
|
||||
### カテゴリ構成
|
||||
|
||||
#### ホーム
|
||||
|
||||
- ダッシュボード
|
||||
|
||||
#### 計画
|
||||
|
||||
- 作付け計画
|
||||
- 施肥計画
|
||||
- 田植え計画
|
||||
- 運搬計画
|
||||
|
||||
#### 実績
|
||||
|
||||
- 散布実績
|
||||
- 畔塗記録
|
||||
- 作業記録
|
||||
|
||||
#### マスター
|
||||
|
||||
- 圃場管理
|
||||
- 作物
|
||||
- 品種
|
||||
- 資材マスタ
|
||||
- 肥料マスタ
|
||||
|
||||
#### 帳票・連携
|
||||
|
||||
- 在庫管理
|
||||
- 帳票出力
|
||||
- データ取込
|
||||
- 気象
|
||||
- メール
|
||||
|
||||
### この分類にした理由
|
||||
|
||||
#### マスター
|
||||
|
||||
- `圃場管理` は圃場マスタとして独立性が高い
|
||||
- `作物` `品種` も本来マスター管理である
|
||||
- `資材マスタ` `肥料マスタ` はすでに独立画面が存在する
|
||||
|
||||
そのため、基礎データ管理を `マスター` に集約する。
|
||||
|
||||
#### 帳票・連携
|
||||
|
||||
- `在庫管理` `帳票出力` `データ取込` `気象` `メール` は完全に同質ではない
|
||||
- ただし、いずれも主作業そのものではなく、補助・参照・出力・連携の性質が強い
|
||||
|
||||
そのため、トップ階層を増やしすぎないための受け皿として `帳票・連携` にまとめる。
|
||||
|
||||
補足:
|
||||
|
||||
- `データ取込` は日常操作ではなく、年度切替時や初期設定時の補助導線とみなす
|
||||
- `メール` は個別トップにしない
|
||||
- `設定` は現状パスワード変更のみなので、右上ユーザー操作に残す
|
||||
|
||||
---
|
||||
|
||||
## 画面と所属カテゴリ
|
||||
|
||||
| カテゴリ | ラベル | パス |
|
||||
|---|---|---|
|
||||
| ホーム | ダッシュボード | `/dashboard` |
|
||||
| 計画 | 作付け計画 | `/allocation` |
|
||||
| 計画 | 施肥計画 | `/fertilizer` |
|
||||
| 計画 | 田植え計画 | `/rice-transplant` |
|
||||
| 計画 | 運搬計画 | `/distribution` |
|
||||
| 実績 | 散布実績 | `/fertilizer/spreading` |
|
||||
| 実績 | 畔塗記録 | `/levee-work` |
|
||||
| 実績 | 作業記録 | `/workrecords` |
|
||||
| マスター | 圃場管理 | `/fields` |
|
||||
| マスター | 作物 | 未実装（allocation 内管理を独立予定） |
|
||||
| マスター | 品種 | 未実装（allocation 内管理を独立予定） |
|
||||
| マスター | 資材マスタ | `/materials/masters` |
|
||||
| マスター | 肥料マスタ | `/fertilizer/masters` |
|
||||
| 帳票・連携 | 在庫管理 | `/materials` |
|
||||
| 帳票・連携 | 帳票出力 | `/reports` |
|
||||
| 帳票・連携 | データ取込 | `/import` |
|
||||
| 帳票・連携 | 気象 | `/weather` |
|
||||
| 帳票・連携 > メール | メール履歴 | `/mail/history` |
|
||||
| 帳票・連携 > メール | メールルール | `/mail/rules` |
|
||||
| 右上ユーザー操作 | パスワード変更 | `/settings/password` |
|
||||
|
||||
---
|
||||
|
||||
## URL とナビゲーションの関係
|
||||
|
||||
### 基本原則
|
||||
|
||||
1. URL はリソース・機能識別子として安定性を優先する
|
||||
2. メニュー構成とは意図的に分離して扱う
|
||||
3. メニュー再編のたびに URL を変更しない
|
||||
4. アクティブ判定はナビ定義側のルールで吸収する
|
||||
|
||||
### 採用理由
|
||||
|
||||
- URL をメニュー階層に合わせて変更すると、既存リンク、ブックマーク、テストへの影響が大きい
|
||||
- メニュー構成は将来も変わりうるため、URL にメニュー階層を埋め込むと変更コストが増える
|
||||
|
||||
### 衝突する既存パス
|
||||
|
||||
| 優先判定するパス | 所属カテゴリ | 除外される側 |
|
||||
|---|---|---|
|
||||
| `/fertilizer/spreading` | 実績 | 計画 > 施肥計画 |
|
||||
| `/materials/masters` | マスター | 帳票・連携 > 在庫管理 |
|
||||
|
||||
通常判定:
|
||||
|
||||
- `/fertilizer` `/fertilizer/new` `/fertilizer/[id]/edit` は `施肥計画`
|
||||
- `/materials` `/materials?tab=...` は `在庫管理`
|
||||
|
||||
---
|
||||
|
||||
## 表示仕様
|
||||
|
||||
### PC
|
||||
|
||||
- 左: ブランド名 `KeinaSystem`
|
||||
- 中央: トップメニュー 5 項目
|
||||
- 右: パスワード変更、ログアウト
|
||||
|
||||
表示ルール:
|
||||
|
||||
- `ホーム` は単独リンク
|
||||
- `計画` `実績` `マスター` `帳票・連携` はドロップダウン
|
||||
- 開いているメニューがある状態で別メニューを開く場合は、前のメニューを閉じる
|
||||
- メニュー外クリック、`Esc` キーで閉じる
|
||||
- 項目選択後は遷移して閉じる
|
||||
|
||||
### スマホ
|
||||
|
||||
- ハンバーガーメニューを採用する
|
||||
- `ホーム` は単独リンクで `/dashboard` へ遷移する
|
||||
- それ以外のカテゴリはアコーディオン形式で開閉する
|
||||
- 現在表示中の画面が属するカテゴリは初期状態で展開してよい
|
||||
- 項目タップ後はメニューを閉じて画面遷移する
|
||||
|
||||
---
|
||||
|
||||
## アクセシビリティ方針
|
||||
|
||||
- トップメニューへキーボードでフォーカス移動できること
|
||||
- `Enter` または `Space` でドロップダウンを開閉できること
|
||||
- ドロップダウン展開後、各項目へ `Tab` で到達できること
|
||||
- `Esc` で閉じられること
|
||||
- 現在位置が視覚的に分かること
|
||||
|
||||
### 初期実装でやらないこと
|
||||
|
||||
- 矢印キーによるドロップダウン項目間移動
|
||||
|
||||
これは Phase 1 の必須要件には含めず、将来のアクセシビリティ強化項目として扱う。
|
||||
|
||||
---
|
||||
|
||||
## 実装方針
|
||||
|
||||
### メニュー定義
|
||||
|
||||
メニュー定義はフラットな `group` 管理ではなく、階層構造で持つ。
|
||||
|
||||
```ts
|
||||
type NavItem = {
|
||||
label: string;
|
||||
href: string;
|
||||
match?: (pathname: string) => boolean;
|
||||
};
|
||||
|
||||
type NavGroup = {
|
||||
key: string;
|
||||
label: string;
|
||||
type: 'link' | 'group';
|
||||
href?: string;
|
||||
items?: NavItem[];
|
||||
};
|
||||
```
|
||||
|
||||
方針:
|
||||
|
||||
- グループ構成そのものが定義から読み取れることを優先する
|
||||
- 通常ケースは `href` ベースで扱う
|
||||
- `href` ベースで判定しきれない例外ケースだけ `match` を持つ
|
||||
- `match` は全件定義用ではなく、衝突回避用の最小限の逃げ道として使う
|
||||
|
||||
### Next.js App Router との関係
|
||||
|
||||
- Route Groups は、URL を変えずにコード構造を整理する手段として有効
|
||||
- ただし Route Groups はナビ判定そのものの代替ではなく、実装整理の補助手段として扱う
|
||||
|
||||
---
|
||||
|
||||
## 段階導入
|
||||
|
||||
### Phase 1
|
||||
|
||||
- トップナビを 5 分類へ再編する
|
||||
- `マスター` 配下に表示するのは `圃場管理` `資材マスタ` `肥料マスタ` のみ
|
||||
- `作物` `品種` はマスター体系には含めるが、独立画面がまだないため Phase 1 ではメニューに表示しない
|
||||
- PC / スマホともに同じ情報設計にそろえる
|
||||
|
||||
### Phase 2
|
||||
|
||||
- `作物管理` `品種管理` を独立画面として追加
|
||||
- `帳票・連携` 内の `メール` を必要に応じてサブグループ化
|
||||
|
||||
### Phase 3
|
||||
|
||||
- 将来マルチユーザー化した場合のみ再検討
|
||||
- 単独利用前提の間は実施対象外
|
||||
|
||||
---
|
||||
|
||||
## 受け入れ条件
|
||||
|
||||
- トップレベルに常時表示される業務メニューが 5 項目に収まっていること
|
||||
- 現在存在する主要画面が、いずれかのカテゴリに漏れなく所属していること
|
||||
- 各画面でアクティブ状態が期待通りに表示されること
|
||||
- PC とスマホで同じカテゴリ構成になっていること
|
||||
- メニューが増えても、トップレベルの項目数を増やさずに拡張できること
|
||||
|
||||
---
|
||||
|
||||
## 参照
|
||||
|
||||
- 議論の背景・判断理由: Gitea Issue `#13 メニューがごちゃごちゃしてきたので、整理する`
|
||||
- 実装向け詳細仕様: `改善案/ナビゲーション再編仕様書.md`
|
||||
Reference in New Issue
Block a user