【Web開発】「無限スクロール」、「確認画面」、「登録画面」、「CSVインポート機能」、「メール送信機能」、「ランキング機能」、「メンテナンスページ」の設計

無限スクロールの設計

最近はスマホの普及で無限にサイトの下までスクロールができるレイアウトが増えています。なので、サイトにページネーションやが必要なくなってきつつあります。（スマホでページネーションをするのはめんどくさいという時代になってきつつあります。）

フッターは？

フッターはPCサイトであれば、右サイドバーのした部分に存在させているサイトが多いです。（yahoo、facebookなど）

例

• Twitter

最近では

従来からあるyahooなどでも聖杯レイアウトなのですが、無限スクロールなどが導入されるようになってきています。

確認画面の設計

通常のWebアプリケーションでは新規登録時は確認画面を実装することが多いですが一概に下記のようにメリットばかりではありません。

確認画面のデメリット

• 登録画面に新しい属性を追加した時に確認画面にも新しい属性を表示させる必要があり手間
• 属性名を変更した際は登録画面と追随して修正する必要がある。
• エンドユーザーが確認画面が表示された段階で登録が完了されたと思い操作をやり直すことになりえる。

なので、確認画面が一概にあった方が良いとは言えないケースもあるのです。実際に使われるケースを想定して本当に確認画面があった方が良いと判断した場合のみ実装するようにしましょう。

画像アップロード機能の確認画面

Webアプリではたびたび画像等のファイルをサーバにアップロードして保存や活用したいという要望はあります。

画像登録をする際に確認画面を挟む場合は「ファイルデータを一時的にどこかに保存する」という少し複雑な処理を実装する必要があります。

登録画面の設計

登録画面作成時の注意点

何も注意せずにフォームの送信ボタンを押して、ブラウザのF5を押すと「フォーム再送信の確認」が表示されてしまう。（「続行」を押すと再度同じ内容を送信する。）

場合によってそれほど問題にはなりませんが、以下のようなケースでは重大な問題になります。

• ECサイトでの商品購入
• モバイルバンキングでの振り込み処理

これを解決するためには「完了ページへのリダイレクト」を使用します。完了ページを別に作成しておいて再読み込みしても完了ページが再読み込みされるだけで再送信がされないようにすることが可能です。

昨今のトレンド

一つの画面に複数項目を入力させるのではなく複数画面に分けてデータを登録更新させるケースが多い。

データの持たせ方

「セッション方式」か「Hidden方式」のどちらかを利用して一時的なデータを持たせる必要がある。

メンテナンスページの設計

あるページがメンテナンス中の場合はメンテナンス中のページにリダイレクトさせます。

CSVインポート機能の設計

csvの不備のチェックポイント

• ファイルを選択していない状態でのインポートをエラーにする。
• 重複データがあった場合は登録を中止する。
• csvの形式チェックをする。

メール送信機能の設計

メール送信機能の用途

Webアプリケーションでは下記のようにメールを送信したい用途が生じる場合が多いです。

• サインアップ
• パスワード忘れ対応
• 通知機能

メール送信機能の一般的な仕様

• 送信元は固定する場合が多い
• テンプレートを用意する。
• HTML形式とテキスト形式どちらも送れるようにする。
• HTML形式を採用する場合は受信者の環境に配慮してテキスト形式の情報も合わせる「multipart/alternative形式（マルチパート形式）」が一般的

メールの形式について

マルチパート形式

不特定多数の方にメールを配信するメルマガでは重宝される配信形式です。受信者の環境に合わせてHTML形式かテキスト形式か切り替えて表示させることが可能です。環境とは、受信者のメーラーの設定によってはHTML形式のメールが展開させない設定になっている場合があるのでその場合はテキスト形式で送信します。

メリット

迷惑メールとして判定されにくくなる。

HTML形式

写真や文字をメールの中に組み込みます。メルマガを使ったマーケティングでは主流となりつつあります。

メリット

• 開封率が高くなる。

デメリット

• セキュリティで弾かれる可能性もある。

テキスト形式

メリット

• 環境に依存しない。
• セキュリティで弾かれる可能性が低くなる。

デメリット

• 開封率が低くなる。

Ruby on Railsでは

Action Mailerという仕組みでメール送信機能を提供しています。

「ランキング機能」の設計

ランキングの特徴

• ReadよりもWriteの割合が圧倒的に多い

RDBで実装

MySQLでスコアのカラムにインデックスを貼ればReadは早くできるが、Write時のindexのツリーを更新するのに時間がかかるため、ランキングのようなWriteが圧倒的に多い処理ではあまり適さないです。

Redisで実装

RedisのSorted SetはSkip Listというデータ構造を採用している。この構造では、登録時に乱択アルゴリズムを使用するので、MySQLのB-treeのようにインデックスツリーのバランシングをする必要がないため平均的に高速になる。

また、ランキングは「ユーザー+スコア」という簡単なデータ集合なのでKVSであるRedisがまさに適している。

注意点

Redisを用いた場合は、データが消えてしまうという可能性も大いにあるためランキング追加時にはMySQLとRedisの両方にデータを追加するなどデータ消失時に対応できるような対策が別途必要になる。