お久しぶりです。コーダーの小島です。

今年ももうすぐ終わりますね。クリスマスが終わったと思ったら次の日にはお正月ムードでいっぱいになる現象には毎年驚きます笑

弊社では先日忘年会もあり、美味しい焼き鳥を食べました！年末は美味しいものが多いので日々誘惑と戦っております。

さて、今回は3カ月にわたってお伝えしてきたベースコーディングレポートの最終回となります。

6.サンプルページを作る③

①ボタン

ボタンはサイト内の別のページや外部サイト、PDFなどの画像を開く際に一番使いやすい部品です。これをクリックすると何かを開くことができるという認識をユーザーが自然にもつことができます。

ボタンを作成するときに注意したことは構造とアニメーションです。ボタンをマウスでホバーした際に起きる動きがわかりやすくサイトのイメージに合ったものとなるよう、コーディングする必要があります。狙い位通りのアニメーションにするためには正しい構造作りが重要になってくるということを強く感じました。サイズの変化に上手く対応し、何度も細かい指示をする必要がないようなシンプルかつ丁寧なコーディングができるよう精進していきたいです！

②カード型リスト

インデックスページと呼ばれる下層ページ内の目次に値するページにはカード型リストを表示します。カード型リストはさまざまな場合に配慮してどんな時もレイアウトが崩れないよう作る必要があるため、カード型リストの作成はサンプルページを作る際に特に苦戦しました。

カード型リストには画像を挿入できるようにするため、どんなサイズを入れても不自然にならないよう工夫する必要があります。また、ページタイトルも短いものから長いものまであるので横に並べたときに一つだけカードが伸びてしまったりしないようコーディングしました。さらに、リンク先によって表示されるアイコンが変わったり、いくつ並べるかも表示するサイズ（PC・タブレット・スマートフォン）選択できるようにしなくてはいけないのでとても難しかったです。

ワードプレス化する場合は私たちだけではなくお客様もカード型リストを作成することが多いため、どんな場合にも対応できる満足度の高いカードリストを作っていきたいです。

③アコーディオン

よくある質問ページなどに登場することが多いのがこのアコーディオンです。矢印アイコンやプラスアイコンをクリックすると質問の答えが表示されるようになっています。

アコーディオンはコーダーがUIを考えて直接デザイン・コーディングする部分が多い部品の一つです。マウスでホバーしたときの挙動、クリックした時の挙動、質問を閉じる時の挙動など場面によって動きをつけていきます。ユーザーがストレスを感じない「使いやすい」UIになるよう日々研究し、どんなサイトにも対応できるよう準備して参ります。

7.トップページを作成する

サンプルページを作成したら、次はトップページを作成します。トップページの作成は別の人が担当することもありますが、弊社ではベースコーディングを担当した人がそのままトップページを作るという場合も多いです。

トップページでは主にメインビジュアル、ナビゲーション、お知らせ欄、おすすめコンテンツ欄などを作成します。サイトによってはワードプレスを部分的に入れることも多いです。

私が初めて担当したサイトはCMS（ワードプレスなど）を入れずhtmlのみで構築するようなサイトだったのですが、画像をフォルダに格納しテキストファイルにファイル名を記入するとメインビジュアルの画像の一枚目にそこに記入したファイルのどれかがランダムで表示されるようなシステムを作って欲しいという依頼がありました。JavaScriptで新しいシステムを作ることは初めてだったのですが、なんとか形になり実装することができたときはとても嬉しかったです。お客様のニーズに応えられるようなコーディングができるよう、これからも精進していきたいです。

また、地図を入れる箇所もあったのですが地域をホバーする仕組みを作るため、クリッカブルマップの作成に挑戦しました。普段使っているエディターとは違うソフトで作成することができると知り、色々なエディターに慣れておく必要があると感じました。

8.ワードプレス化する

今回はワードプレス化する必要はなかったのですが、Web知識のない方でも簡単に更新できるよう、サンプルページの共通パーツやトップページをワードプレス化します。

私自身、部分的にワードプレス化をしたことはあるのですが、1からワードプレスを導入したことはないので機会があれば挑戦してみたいです。

9.Googleアナリティクスを導入する

Googleアナリティクスはそのページがどんな人にどれくらいみられているかを解析するためのツールです。複雑な手順を踏む必要があるため、初めは手探りでしたが、一つ一つ丁寧に進めていくことで実装することができました。

Googleアナリティクスの解析はサイトを運用・更新していく上で最も大切な指標になっていくので実装にも力が入ります。より良いサイトづくりの一助になっていることを実感できるとても重要なステップだと感じました！

10.納品リストをチェックする

サイトの量産は完了したら納品リストをチェックしていきます。画像にaltは指定されているか、favicon・Meta・OGPは設定されているか、リンク切れしていないか、速度に問題はないかなど多岐にわたる項目をチェックしていきます。納品リストのチェックは必ず複数人で行い、漏れが起こらないよう徹底しております。

問題がないか緊張しつつも納品チェックをしていると同時に達成感も感じました。世に一つのサイトを送り出したのだということを改めて実感し、とても感動しました。

初めてのベースコーディングレポート後編まとめ

初めてベースコーディングに挑戦していく中でたくさんの気づきと学びがありました。実際に1からサイトの開発に携わる中で数多くのサイトを作ってきた弊社が培ってきた「ノウハウ」があるからわかりやすく使いやすいサイトが制作できるのだということを実感しました。入社してまだ半年とまだまだ未熟ですがいち早く貢献できるよう、私も努力して参ります！

弊社ではwebサイト制作のほかにもチラシの作成や、動画制作なども行っていますのでぜひお気軽にご相談ください！

▼webサイト

https://www.medical-design.co.jp/works/web.html

▼グラフィック

https://www.medical-design.co.jp/works/graphic.html

▼写真撮影・動画

https://www.medical-design.co.jp/works/photo.html

こんにちは！コーダーの小島です。

あっという間に冬になり、今年も終わろうとしていますね。御茶ノ水にもちらほらイルミネーションやクリスマスツリーが出現していて、休憩時間や帰り道に癒されています。

皆さん今年はどんなことがありましたか？私はメディカルデザインに入社し、様々な新しいことに挑戦したとても濃い一年だったなと思います。来年はより成長できるよう精進してまいります！

さて、先月に引き続き今月は私が初めて挑戦した「ベースコーディング」の中で行ったサンプルページのコーディングについてお伝えしていきます。

5.サンプルページを作る②

下層ページ共通で表示されるheaderとfooterが完成したら、サンプルページの中身を作っていきます。サンプルページはあまりクラスをつけすぎずにシンプルな構成かつ、柔軟に作らなくてはいけないのでとても難しいなと感じました。形になればいいというわけではなく、どんな条件でも崩れない、誰が下層ページを作成しても同じ形式になるよう工夫する必要があるということを認識しました。それでは、一つ一つのパーツを作る中で感じたことを書いていきたいと思います！

①キービジュアル

キービジュアルとは下層ページの印象を決める大きな役割を果たしています。キービジュアルがあることにより、サイト全体の統一感が出るなと常々感じております。ページタイトルやパンくずリストがキービジュアルに表示されることも多いので、そのページの顔とも言えるパーツだと思います。

今回私が作成したサイトのキービジュアルはキービジュアルと記事の内容の境目が波状になっていました。トップページも同じようにメインビジュアルが波状に切り取られていたのでとても統一感があって素敵なデザインだと感じました。

この波状の画像ですが、ただ波状のまま書き出すわけではありません。Photoshopから波状のまま書き出すことは簡単なのですが、キービジュアルを更新する際にデザインデータがないと書き出せませんし、何よりとても手間がかかってしまいます。今回も最小限の更新で抑えるためにも、波状のまま画像を書き出すのではなく、背景色に合わせた波状のマスクを作成し、擬似要素で画像に書き出すという方法を取りました。

またそのまま書き出す場合より、スマホやタブレットでの表示に合わせやすいというメリットもあります。今回のキービジュアルの作成を通して色々な立場から考えることが必要なのだと学びました。

②アンカーリンク

アンカーリンクはそのページの目次のような役割をしています。ページの内容の先頭に表示され、見出しの多いページの中から目的の内容を見つける道標、まさにアンカー（錨）の役割をしています。

アンカーリンクを作成する際に苦戦したことはどのように折り返すか、ということです。
見出しのテキストが長い場合やアンカーリンクの数が多い場合でもデザインを保っていなくてはいけません。私はつい、デザインの文字数に合わせてコーディングをしてしまいがちなのですが、色々な場合を想像しコーディングするようにしないとどんどんコードが複雑かつ柔軟性に欠けるものとなってしまうことを痛感しました。

矢印のアイコンの位置はテキストが折り返しても不自然な位置になっていないか、文字が途中で折り返されていないかなどたくさん検証することが重要だと感じました。

③見出し

弊社では大体、h2、h3、h4、h5、h6と６つの種類の見出しを用意します。

内容に合わせて多様な見出しがあると量産の表現の幅も広がり、ワンパターンではないより充実したサイトになります。このように特別なタグの場合はよりシンプルな作りにすることが重要なのだと感じました。見出しのタグを打ち込んだだけでクラスがなくても同じスタイルが表示されるようなコーディングが必要です。

また、見出しと見出しの間余白を作る際も、より柔軟なコードにしておく必要があります。つい、目の前に表示されているサンプルページのデザインにとらわれてしまい、より正確なデザインになるようピクセル単位を多用してしまうのですが、よりレスポンシブなサイトになるよう適した単位を選べるようになるということが今の課題です。

④本文テキスト

本文で使用するテキストのパーツは簡単なようでとても奥が深いと感じました。同じ段落のテキスト同士の行間、違う段落同士の行間、1pxでも違うと見やすさが全く違うことにとても驚きました。実際に量産した際に最も感じた違和感の一つが本文テキストの行間でした。サイトを見た人がストレスなくページを読み進められるよう、簡単に終わらせずここにもこだわることが大切だと認識できました。

また本文テキスト内のリンクのスタイルもつけていきます。どの位置にリンクが表示されても違和感がないようコーディングするのはアンカーリンクと同様にとても難しかったです。ホバーする際のアニメーションの速度など、細かいところにまで気を配ることが洗練されたサイト作りにつながっていくのだと感じました。

⑤テーブル

内容に合わせて適したグラフを表示することができるよう、今回は3つのテーブルのスタイルを用意しました。

一つ目は表がそのまま小さくなるスタイルです。表に入るテキストが少なく表の見出しの数も少ない場合はこのテーブルを使います。とてもシンプルではありますが、このテーブルのスタイルが基準になるのでクラスをつけずに表示したときはこのテーブルが表示されるようにコーディングしました。今までテーブルにスタイルをつけるときはたくさんクラスをつけてしまっていたので最低限のhtmlだけを使ってデザインを再現するのに苦労しました。

2つ目は横の表見出しのないテーブルです。この場合はスマホサイズになったときに縦の表見出しと内容が縦に表示されるようにスタイルをつけました。

3つ目はレスポンシブテーブルです。このテーブルはスマホサイズで表示した時に横にスワイプすると内容が確認できるようにコーディングします。スマホサイズになるとフィルターが表示され、スワイプできることを示す指マークが表示されるようになっています。htmlとcssだけではなくJavaScriptも必要になってくるので他のテーブルのコーディングより少し難易度が高かったです。表現の幅を広げるためにも、もっと勉強してスキルを身につけたいと思います。

⑥リスト

弊社では3種類のリストを作ります。通常使用するulリスト、順番のあるリストに使用するolリスト、リンクがある時に使用するリンクリストです。本文テキスト同様にリストは行間によって読みやすさが大きく変わるパーツになっています。また、リストの先頭に表示するアイコンの位置も適切になるようにする工夫が必要なのでたくさん修正をしました。

初めてのベースコーディングレポート中編まとめ

今回はベースコーディングの中でも特に重要なサンプルページの作成についてお伝えさせていただきました！思った以上に書くことが多く、それだけベースコーディングをする中で得た知見の多さを実感しました。たくさんの実績を持つ弊社だからこそ様々なシチュエーションに対応できる柔軟なサイト制作をできているのだなと改めて実感しました。

次回はベースコーディングレポート最終回をお届けしたいと思います！

弊社ではコーディングだけでなく、取材やデザインなども幅広く行っております。
興味をお持ちの方は是非一度ご相談ください。

ご相談はこちらから↓
https://www.medical-design.co.jp/contact/

こんにちは！コーダーの小島です。
10月に入ってどんどん涼しくなってきましたね。特に朝と帰りの通勤時間はちょっと寒いなと常々感じております。このくらいちょうど良い気候はなかなかないのでできるだけ長く続いて欲しいです。

さて、今回初めてベースコーディングに挑戦したので、その様子を感想ベースで共有させていただければと思います。

1.Gitのリポジトリを作る

まずリポジトリの名前を決めます。基本的にサイトをリニューアルするときは現行しているサイトのURLを元に決めます。同じサーバーを使用しているサイトがある場合は一工夫必要なので要注意です！被らないよう命名規則に従ってリポジトリ名を決めていきます。

次にリポジトリの設定をしていきます。このとき”add gitignore”にチェックを入れておくと不要なファイルがGitにアップされずに済みます！この一手間で不要なファイルを削除する手間を省略させることができます。実は今回、初めにこの一手間をスキップしてしまった影響で不要なファイルが生成されてしまい、削除する手間が発生してしましました…
もっと効率よくコーディングを進めるためにも先輩方からどんどん新しい知識を学んで、次に活かしていきたいなと思います！

そして作ったリポジトリに会社のメンバーのアカウントを招待します。開発中のアカウントはプライベートモードになっているのでチームを招待しないと自分だけしかそのリポジトリで作業したり、更新したりすることができません。

Gitはチームで円滑にコーディングするためにとっても重要なツールだなと日々感じています。更新や運営をするときにも重宝するのでその元を作っているという意識をしっかり持って慎重に作業していきたいです！

2.チャットグループを作る

まずはそのサイトを作るチームの皆さんとコミュニケーションを取るためにチャットグループを作ります！弊社ではChatworkというコミュニケーションツールを使用してチームで協力をしてサイト制作に取り組んでいます。

チャットグループにチームのメンバーを招待したら、概要を入力していきます。本アップまでのざっくりとしたスケジュール、ディレクターさんがお客様と相談しながら作成したサイトマップのリンク、テストアップサーバーのサーバー、テストアップサイトのリンク、backlog（お客様とコミュニケーションを取ったり、どのようなサイトを作るかをまとめることが簡単にできるツール）で立てた課題（それぞれのプロジェクトごとに作ることができ、プロジェクトごとに情報をまとめたり、チャット機能を利用してコミュニケーションを取ることができる）のリンクなどを入力します。これをすることにより、各々がそれぞれ担当のページをスムーズに作成することができます。

余談ですが、チャットグループを作った人はチャットのアイコンを決めることができます！（時間に余裕がある時ですが…）サイトに関係のあるかわいいアイコンを見つけて設定することが密かな楽しみにもなっています。笑
デザイナーさんが作ったかわいいアイコンを見るとこんなにシンプルでかわいいのにひと目見ただけでなんのアイコンかわかるのは流石だなといつも感動します！

3.サイトの骨組みを作る

Gitとチャットの準備ができたらサイトの骨組みを作っていきます。
そのサイトがワードプレスで簡単に更新できるようにするか、ファイル納品（弊社でサーバーを用意せずにデータのみの納品をすることも稀にあります！）にするか、何の言語でコーディングするかを参考に以前弊社で作成したサイトを元に新しいサイトを作っていきます。

この参考にするサイトを見つけるという作業が意外と難しく、より効率良くベースコーディングに取り組むためにとても経験が必要な作業だと実感しました。初めてということもあり、今回は先輩方にアドバイスをいただいて元にするサイトを決めましたが、自分で広い視野で先読みをして自分の力で判断できるよう経験を培っていければと思います。

元にするサイトを決めたらそのデータを複製して元になったサイトの気配を消す作業に入ります。不要なデータを削除し、必要最低限の情報を残します。古いバージョンのプラグインがローカルに保存されている場合は最新の物をダウンロードし直し、差し替えます。日々アップデートされるプラグインをより良い状態で使うためです。ダウンロードしたプラグインを使うことでアップデートによるバグなどを防ぐこともできます。

サイトの骨組みを作る工程における一つ一つの心がけによってお客様が安心して運営できるサイトの基礎を固めるとても重要なポイントだと今回改めて認識いたしました！

4.サンプルページを作る①

骨組みを作ったら、実際のコーディングに入っていきます。今回私がベースコーディングに挑戦したサイトはファイル納品かつhtmlのみで作成するサイトだったのでイレギュラーな部分が多かったのですが、とても良い経験ができたなと感じています！

サンプルページを作る手順は前回の記事でも軽く触れたかと思いますが、まずはデザインから画像を書き出すことから始まります。その中で今回特に苦戦したのがストライプ模様の背景の素材を書き出すことです。
規則性のある画像は一部を切り取って反復させて表示させるやり方があるのですが、その反復させる画像の書き出しに苦戦しました。いつものように画像を書き出すと画像の周りに余白ができてしまい綺麗なストライプにならないという現象が起きてしまいました。
選択範囲を利用してクリッピングマスクを作成していたことが原因で、オブジェクトを使用してクリッピングしたところ余白のない綺麗な画像を書き出すことができました。一つのやり方に固執せず、場合によって柔軟に対応できるようPhotoshopの知識の幅も広げていきたいなと思います！

画像が書き出せたらまずはheaderとfooterを作っていきます。今回はheaderが途中まで表示されて消えるというUIだったのでユーザーが使用したときに心地よいスピード感になるようJavaScriptを使用して調整しました。速すぎず遅すぎない心地よいスピード感が身につけられるよう色々なサイトを見て研究していきたいです。

また元にしたサイトがPHPで記述されていたのでheaderとfooterの記述を直接書き直し、htmlでも表示されるよう工夫しました。
headerとfooterを作ることができたらサンプルページの中身を作っていきます。

その詳細は来月のブログで書かせていただきたいと思いますので、どうぞよろしくお願いいたします！

初めてのベースコーディングレポート【前編】　まとめ

今回は私の初めてのベースコーディングについて共有させていただきました。
先輩方にご教授いただきながら挑戦する中でより良いサイトの開発をするための工夫やその先の運営への配慮を知り、とても勉強になりました。
弊社では長く運営できるだけでなく細かいUIにも配慮し、離脱率の低いサイトを作成しています。少しでもご興味をお持ちの方はお気軽にご相談ください！

ご相談はこちらから↓
https://www.medical-design.co.jp/contact/

システム部渋谷です。

このごろはレスポンシブデザインでのWeb制作が当たり前のようになってきました。
レスポンシブデザインでは閲覧環境に合わせて見え方を変える都合上、大きな画像を用意してそれをブラウザ上で縮小させて表示することになります。

「レスポンシブで縮小した画像がIEだけ汚い…」

古いIEが消えてだいぶましな描画がされるようになったほのぼのIEだったのですが、またしても問題に！

この画像を各ブラウザで縮小してみてみると…

あたかもニアレストネイバーで縮小したかのような汚さなのですが……。
（縮小したものをニアレストネイバーで2倍に拡大しています）

各ブラウザの画像補完について

どういう処理をしているのかを調べるために、画像を縮小拡大になんのアルゴリズムを使ってるのか見てみました。

上の画像は、小さい画像を大きく表示させた場合どう表示されるかを表したものです。
8×8の小さな画像を256×256に引き延ばしています。
上段はPhotoshopで作った参考画像で、下段は各ブラウザでの表示結果。

もしかしたら画像によって、または縮小と拡大によって切り替えているかもしれませんが、
IE11：バイリニア
Edge：バイリニア
Chrome：バイキュービック
Firefox：バイリニア
という結果でした。
バイリニア以上を各ブラウザがデフォルトとして使ってることは確定のようなのでそんな汚くならないと思うんだけどなぁ…と。

今度は別な画像を使っての縮小テスト。
しましまな横512の画像を横63に縮小表示させています。
割り切れない微妙な数字にするのがポイント。

IEとEdgeだけ妙な縞になってます。

バイリニアでは求める位置のピクセルと周囲の1ピクセルを線形的に補完するため、半分以下の大きさに縮小する場合一度半分の大きさにして、そこから再帰的に小さくしていかないときれいな画像になりません。
（無視して捨てられるピクセルがたくさん出てくる）

元の画像が大きければ大きいほどニアレストネイバーに表示結果が近づいていくことになります。
そのぶん処理は軽くなりますが。

上記結果からの推測になるのですが、おそらくIEは処理を軽くするために意図的に2回目以降の縮小処理を省いているのではないでしょうか？

……あくまで推測ですが。

ChromeとFirefoxでは画像が半分まではしましま、半分以下はどのサイズでもグレー1色になりました。

結局のところ対処法は…

元の画像の半分の大きさになるまではきれいに縮小されるので、半分以下の大きさにならないように気を付ける必要がありそうです。

システム部の渡辺です。

前回記事「
ウェブアクセシビリティのJIS規格対応」の続きで、

具体的な作業に関する部分を書きたいと思います。

アクセシビリティのJIS規格「JIS X 8341-3」の詳細がわかる公開されているページは現在、

公式ページ「実装チェックリストの例 2012年11月版」

になります。

38項目のリンク先ページに約10個ぐらいの対応内容が書かれていますので相当な量になりますが、基本的に常識的なWEB制作をしていれば大抵のものはクリアできるかと思います。

私個人の判断で、

「あまり一般的ではない内容」と

「登場頻度が多く、うっかり忘れてしまいそうな内容」を

「デザイン時」「コーディング、特にベース部分制作時」「コーディング、特に各ページの制作時」に分けてピックアップすると下記の表のようになりました。

もし参考になりましたら幸いです。

• ※ 上記は動画に関する項目は省いています。サイト内に動画を設置する場合は気をつける点が増えます
• ※ 「達成基準」の部分を、公式ページへのリンクにしています。

デザイン時に気をつける項目

コーディング、特にベース部分制作時に気をつける項目

コーディング、特に各ページの制作時に気をつける項目

システム部の渡辺です。
ユーザビリティという言葉はよくききますが、
アクセシビリティについて説明するのはなかなか難しいのではないでしょうか。

アクセシビリティといえば高齢者・障がい者の方々を考慮したWEBコンテンツ、
病院サイト、介護老人施設サイトなどを多く扱う弊社では特に気を使う点です。

一般的に制作時に気にする点といえば、

「視力が悪い人が困らないように大きくてわかりやすい色の文字を使う」
「画像の alt 属性を記入する」

このぐらいかと思いますが、
日本で定められているアクセシビリティ規格を正しく守るには、

「音声読み上げを考慮したコーディング」
「キーボードだけで全ての操作を可能にする」
「CSS、Javascript をオフにした状態の対応」

など、普段あまり触れることのない対応も必要になってきます。

公的機関の公式ホームページのウェブアクセシビリティ

厳密にどのように対応すべきか、というところですが、
日本国内では JIS（日本工業規格）の中で規格が定められてます。

公的機関ではアクセシビリティ対応を試験されています。
「公的機関におけるウェブアクセシビリティ方針策定と試験結果表示の実態調査（2014年11月）」
例えば、東京都では、「東京都公式ホームページ作成に関する統一基準」というものが決まっています。

東京都立○○の公式ホームページなどを制作する場合、上記に注意する必要があります。

JIS X 8341-3対応

JIS X 8341-3対応のサイト制作をする場合は、
サイトを作る前から充分に気をつけたいところです。
正直、JIS X 8341-3対応するつもりでつくっていなかったサイトを、
JIS X 8341-3対応するのは、かなり骨の折れる作業です。

• デザイン時に気をつける項目
• コーディング、特にベース部分制作時に気をつける項目
• コーディング、各ページ固有の制作時に気をつける項目

の3つに分けて、注意したい対応項目をまとめたいと思いますが、
長くなったので次回に!

更新したはずなのに!

HTMLの更新完了! お客様、ご確認ください、というシーンで

お客様「変わってないようだけど?」

ブラウザに残ったキャッシュの可能性がありますのでキャッシュの削除を・・
削除方法は・・ブラウザは何をお使いでしょう?というようなやりとりがまれにあるかと思います

原因は?

見る側のパソコンのブラウザに残っていた古いデータ(キャッシュ)が
更新後の初回アクセス時に使われてしまい、
ページが予期せぬ表示になってしまうあの現象です。

どうしたらいいの?

つまり見る側のパソコンのブラウザに
「このCSS、今回は新しく読み込んでくださいね」と、どう教えるかですが、
てっとりばやく簡単な方法として

例えば、今までこう書いて読み込んでいたCSSだとしたら、

キャッシュ更新したい時はこう変えます

その読み込むCSSのパスの最後に「?」をつけまして、
でたらめな文字をクエリとして渡すと、

ブラウザ「このCSSは、今までと違うこの値によって、違うデータに変化するかもしれない」

と認識して新しく読み込んでくれます。

上記の例の「default.css?20150802」は年月日ですが、
「?」の後は、URLとして意味を持たない文字列なら何でもいいです。

レイアウトを大きく変えるときなどちょっと加えておくと、
大きなタイムロスと信頼感へのダメージを未然に防げますので、
おまじないのように入れておくといいと思います!