よく使われるフォームについて(ユーザ辺)
よく使われるフォームについて
エンジニアをやっていると、フォームを作成する機会が多いのですが、各項目はどんな命名が良いのかで迷うことがあります。 今回は私の中でよく利用される命名とその意味合いを紹介出来ればと思います。
ユーザ関連フォーム
名前
個人的には「name」がベストだと思いますが、 たまに「名字と名前を分けたい」というリクエストをうけることがあり、 その場合は、「first_name」「last_name」にしています。 過去に「f_name」「l_name」というケースも見たことがありますが、 「family name」と「given name」での[f]なのかわからなくなるので、 略さずに「first」「last」を使用しています。 私は世界展開したサービスでの開発経験はないですが、 海外も対象にした場合は、「middle_name」を追加する場合があるかと思います。
メールアドレス
これは幾つかの派閥があるかと思うのですが、 私は「email」派です。 理由としてはRonRで用いるdeviseというgemやcakephpやjquery.validate.jsのバリデーションなど多くのフレームワークの初期設定が「email」だからです。 おそらく派閥が一番多い派閥ではないでしょうか？(気になる方はgitのソース検索などしてみて下さい。) 次に大きい派閥としては「mail」派閥が大きいでしょう。 そもそも「email」の「e」は「Electronic(電子)」なので、 「mail」派閥からすると「Electronicじゃないmail使うやついんのか？文通の情報を間違えて入れないように[e]をつけてんのか？文通の情報ってなんだよ!!」と思っていることでしょう。 正直気持ちはわかります。 実は私も昔「mail」派閥でしたが、長いものには巻かれた方が幸せになれるという甘い言葉を信じて「email」派閥になった過去があります。 少数派閥としては「mailaddress」「emailaddress」「e_mailaddress」と言った派閥もありますが、巡り合う事はそう多くないでしょう。 メールが中心となるサービスですと、 「pc_mail」「mobile_mail」と端末で別れていたり、 「mail_01」「mail_02」と2つのアドレスに対してメールを送る機能を求められる場合があります。 なお、「片方に送って送信が失敗したらもう一方に送る」という仕様の場合は、 「main_mail」「sub_mail」と私だったら命名します。 (前後に何か付く場合は「email」でなく「mail」にします。)
また、メールについてはバリデーションをどこまで厳しくするべきか問題もあり、語ることは多いですね。
キャリアによってメールの条件が異なったりしています 使用するフレームワークによりバリデーションの内容は様々です railsでは専用のgemもあります
郵便番号
これは「zip_code」がほとんどではないでしょうか？ 最近の若い世代は知らないかもしれませんが、昔は「post_code」が使われていましたが、 いつの間にか「zip_code」が当たり前になっていましたね。 「post_code」が「zip_code」になった理由はおそらく、 「post_code」ですと「役職コード」や「投稿コード」といった誤解を招くからだと思われます。 ただし、まだ決着がついていないのが、 「zip_code」は「-(ハイフン)」をありで登録するべきか、無しで登録するべきか問題 ですね。 私は「-無し」のint型で登録をしたいタイプです。 理由としては、バリデーションのシンプルさ、整形の不必要制ですね。 「-あり」はの方の意見としては、 ・ そもそも郵便番号・バーコードマニュアルに記載されている ・ 人間が見やすい という理由かと思います。 稀に、「zip_code01」「zip_code02」とハイフンの前後で別カラムに分けるタイプの方もいらっしゃいます。
住所
住所についても実は奥が深い問題になります。 日本では、 「都道府県」「市区町村」「地区・町名」「番地・丁目」「ビル・マンション名」「階数」「部屋番号」 と言った項目が必要になりますが、正確さを求めるとなると、 「支庁」「字(あざ)」といった項目が必要になったりします。(細かいことは調べていただければと思います)
特に集計したり、地域別戦略性を行う可能性がないのであれば、 「address」の欄に全部をテキストで入れてもらいたいのですが、 「不動産」「旅行」関係など住所が大切なデータになるサービスですと、 日本の住所データを購入し、表記ゆれの無い様にプルダウンにしなければなりません。(代々木 or 代代木等) データの購入は国土地理協会か株式会社ゼンリンデータコム様から購入するのは多いかと思います。
そういった際は以下のような命名が多いかと思います。 都道府県 = prefecture 市区町村 = city 地区・町名 = area 番地・丁目 = address ビル・マンション名 = mansion 階数 = floor_number 部屋番号 = room_number
都道府県だけプルダウンで後は、「その他住所(other_address)」とする場合も多いと思いますので、どこまでやるかはそのサービスにおける住所データの重要性によって異なると思います。 更に言うと、郵便番号検索機能を用いる場合は・・・以下略。
見た目上の話ですと、日本一長い住所や道順を住所にしたいわゆる「京都式」をどこまで考慮するのかといった問題もあります。 (私は基本DBには255文字まででレイアウトは30文字程度が入ればokにしていることが多いです。) 京都府京都市東山区三条通南二筋目白川筋西入ル二丁目北木之元町 京都式
電話番号
電話番号は1カラム派所属ハイフン無し派と、1カラム派所属ハイフンあり派、と3カラム派の3派閥が存在しますが、 私は1カラム派所属ハイフン無し派に属しています。 理由としては、郵便番号同様バリデーションのシンプルさ、整形の不必要制ですね。 「tel」カラムをint型にしたい派です。 「telephone」「telephone number」でも良いですが、3文字で本来の単語の意味を損なう事なく収まるのであれば、3文字の方が楽でいいかと思います。
バリデーションにおいては「国際電話対応」「()を入力された場合」の論争が起きることも稀にありますので、ご注意下さい。
生年月日
これは「birthday」1択かと思います。 なお、登録してから、日付が経過して、誕生日を迎える場合があるため「年齢(age)」カラムを持たないのは隠れた常識ですので、[age]カラムを見つけた時は特別な意図があるか確認すると良いでしょう。 型はdate型かdatetime型が多いですが、 占いをメインとしたwebサービスで、多く星座を使用するため、「年」「月」「日」とカラムを分けているサービスに出会ったことがあります。 (それでも分けなくて良いのではないかと思いましたが。。。)
性別
性別は「gender」が多いでしょう。 また、世の中の流れに合わせてtinyint(1)やbooleanではなく、 int型で「その他」を用意するのがワールドスタンダードになってきています。 ちなみに、 gender = 社会的な性 sex = 肉体的な性 という意味合いを持っているようですので、動物の管理をしているところでは命名が変わっているのかもしれません。
役職
役職は「position」かと思いますが、 求人系ですと、プルダウンの中に「管理職」「正社員」「派遣」「アルバイト」といった項目に別れ 「役職」と「職業形態」が一緒になっているケースもあり、 「job_type」に近い役割の場合もあります。 どんな入力を求めているかによって変える必要があるでしょう。
仕事
仕事は「job」かと思います。 求人系で「理系 > IT系 > エンジニア」となっている場合は、 「system > job_type > job」でしたが、もっといい命名があるような気がしてなりません。
趣味・特技
いままでは趣味・特技は入力してほしい内容が 「暇な時何してる？」くらいのものであれば「hobby」 「これは簡単には負けないみたいなのある?」ならば「skill」 といった感じにしていましたが、実際の英語で[hobby]はあまり使わないらしいので、[skill]でいいのかもしれません。
目的
大きいサイトのフォームによくある 「XXの管理がしたい」「XXを増やしたい」「XXについて情報がほしい」 と言った登録した目的にあたる部分ですが、 「purpose」が多いですが、場合によって「reason」を用いる場合もあります。
プロフィール
シンプルに考えると「profile」ですが、 ここの内容が読んで終わりではなく、サービスとして重要な役割をはたすのであれば、 「description」や「pr」でも良いかもしれません。
終わり
書き出したら本来書きたかったものと大きくずれてしまったので、そのうちリベンジがしたいです。 ユーザや問い合わせのフォームは先人たちはいろんなフォームライブラリやバリデーションライブラリを残してくださっているので、それを賢く駆使しすると良いかと思います。 また、いろんなサイトのフォームをデベロッパーツールで覗いて見るのも楽しいかもしれません。
