カテゴリー別アーカイブ: 画面遷移

シンプルに考える

僕が設計や、実装をする上で心掛けていることに、
「可能な限りシンプルに」ということがあります。

例えば、システム構成。
複数台のサーバーで構築するより、1台で構築した方が、
プログラムの更新を反映するにしても、トラブルの原因を突き止めるのも、やりやすいです。

例えば、テーブル定義。
慣れないうちは、一つのテーブルに様々なカラムを入れてしまいがちですが、
適切なテーブルを、適正な関係で複数のテーブルを作成した方が、
データの登録・更新するには、行いやすいし、パフォーマンスもでます。

例えば、画面遷移。
最近ではSPA(シングルページWebアプリケーション)、
いわゆる1ページで完結しているサイトが、
スマホの普及とともに、どんどん増えてきいます。
ただ、僕はSPAはあまり好きじゃないです。
確かに、ページ遷移がないので、ユーザーはクリックして、
待たされることなく、次のページを見ることができますが、
作る側にとっては一つのページで処理することが増え、
デバッグにも手間がかかるようになります。

先日も、とある映画を見るために、某映画館のサイトを使いましたが、
SPAである場合、リロードする度にそれまでの入力がクリアされるために、
高負荷で繋がりにくくなった場合に、同じ情報を何度も入力する手間が出てきます。
シンプルに 1ページ 1役割にすることで、そうした状況がなくなります。

今回、僕が g’s cms で登録時のフローを考えた際の遷移図が以下になります。

seni1

GitHub上のソースと合わせて見ていただけばと思います。
Topページは index.php で「登録されている一覧を表示」する。
ページ下部に、登録ページ用のリンク regist.php を張り、
「登録情報を入力だけさせる」ページを作成する。
このページで登録した情報は、[登録]ボタンを押すことで、
「登録処理を実行する」 regist_execute.php に遷移。
ただ、登録を実行する URL をユーザーに見せてしまうと、
この URL に対して不正なリクエストをする人が出てきたりするため、
不可視な phpページとして作成し、
処理中にエラーが発生時は、regist.php にリダイレクトし、
成功時は、「登録完了を知らせる」 regist_complete.php に、リダイレクトさせる。

こう作ることで、1ページに 1役割を持たせた画面構成になる上に、
不正な登録を試みるユーザーに対する、若干のけん制にもなります。
(実際は regist.php のソースを見れば、formの先がregist_execute.php であるのは、
この構成では明らかですが、そこはまた別の話)

今回は画面遷移を設計することについてとりあげました。
ただ、「シンプルに考える」というのは、今後、いくつかの場面で、取り上げることになるかと思います。
その際に心の片隅にとどめていただいてもらえればと思います。

次回は、「入出力を意識する」ということについて、取り上げる予定です。

広告