💡
登録画面は必要なのか？
※まだ全く思慮してないです。ただ今後考えることがあるかもなのでメモしときたいなと。
登録画面は必要なのか？
TODOアプリや蔵書アプリなど、登録できる内容は違えど、大体以下の機能が構成されていると思います。
- 一覧表示
- 新規登録
- 編集
今回このような機能を持ったアプリで考えていきます。
イメージ図だとこんな感じ。この図の②の画面にどれほどの必要性があるのだろうと、ふと思いました。
仮にTypeScriptで作るとしたら↓なファイルになるでしょうか。
- 一覧画面（BookList.tsx）
- 登録画面（AddBookForm.tsx）
- 編集画面（EditBookForm.tsx）
もちろん設計次第でAddBookFormとEditBookFormを一つのファイルにする（あるいはロジックを切り出して、AddとEditでファイルは別だが共通処理はまとめる）ことは可能と思いますが、上手な設計を考えるのも手間だと感じてます（技術がないだけかもですが少なくとも僕は...）。
そして実際にAddとEditでロジックもコピペで作ってる会社さんもまだまだ多数あると思ってます。
これで良くない？と思った画面構成
上手な設計をすんなり考えられる人とかテンプレ化できてる人は問題ないですが、そうでない場合は以下のような画面構成にしても良くないかと感じました。個人的には特にUXに対して違和感を感じてないです（といいつつ全くパターン考えてないので色々困ること出てくるかもですが）。
今後ゆっくり考えたい。
Discussion
分かります…。自分も「新規作成ページはなくて良いよね」派だったのですが、以前ユーザーさんから「新規作成ページを作ってほしい。ブックマークしておくと1クリックで記事を書き始められるから」という要望を受けてすごく納得した記憶があります。
それからは「気軽に投稿できる」と謳うWebサービスではできる限り新規作成ページも用意するようにしています。一つの視点として参考になればと思いコメントさせていただきました 🙏
おぉ！コメントいただきありがとうございます！！
なるほど...。私がこんな使い方した経験がないので完全に盲点だったのですが、言われてみると確かにコアユーザにはめちゃくちゃ需要ありそうですね！
今後の方針として凄く参考になります！ありがとうございます！
コメントありがとうございます！！
これは本当にそうですね...w 私も元々SIerで働いてまして、（最近流行りの自社系web開発企業と違って）お客様の提示した仕様から1ミリもズレちゃだめ（極論な表現ですがw）な環境でお仕事させて頂いてたので、なかなか技術者の思う理想と要件のマッチは難しい場合がまだまだ多いですね...
仕様を増やしてしまうのであまり良くないと思いますが、id=0の時は新規登録にするという風にすると編集画面と新規追加画面を一体化できますね。
ただ、「新規画面なら○○できるけど、編集画面だと○○できません。」があると困るので何とも言えないですね
これも割と面白いですね。結構やってる会社さん見かけます。
ただ記載されてる通り、複雑化しそうな予兆あるので個人的には避けたいところ....
ここ1~2年、新規作成ページに関しては関心事になっていたので嬉しい内容です。
（ https://zenn.dev/stin/articles/remove-new-form-design の話題から目に止まったので今更ですがコメントさせてください）
自分の場合、業務管理ツールとして新規作成ページについて悩んでいましたが、たどり着いた答えは「必要最小限の項目だけを入力させるUIにする」でした。新規作成後は、nabeさんの案のように追加後すぐ編集画面に遷移させる感じで同意見です。
ここで言うところの「②登録画面」と「③編集画面」を似たUIにもせず、タイトルだけは必須として入力させるようにする形ですね。（もしくは、蔵書アプリとして重要なのは絵の一覧性であるならばタイトルではなくサムネの写真登録が1番重要なのかもしれません）
当たり前な結論ですが、新規作成ページもアプリとそのユーザーに則したUXを考慮しなきゃね、という感じでしょうか。
nabe workさんの案を見てぱっと思ったのは、DBレベルでNOT NULLにしづらそうだなと思いました。
TODOアプリや蔵書アプリなど、という前提なので画面側でバリデーションできれば十分かもですが...
あとは、従来案だと新規登録画面まで1クリックで遷移できますが、nabe workさん案だと2クリックに増えているので、そこもユーザーの使い勝手をどこまで意識するかで採用する案が変わってくるかなと思いました！