自分のwebサイト作る工程

webサイトどういう工程で作ってるんですかって訊かれたことがあったので、だいたいこういう流れで作ってますっていうのをまとめる。

自分のウェブサイト(http://www.sanographix.net/)を2月くらいに作りなおしたので、それを例にする。

1. ラフ書く

いきなりコーディングを始めるということはあまりしなくて、まず紙にラフスケッチ描く。今風に言うとペーパープロトタイプつくる。理由はすぐ作れるから。紙、10分もすれば描ける。後述するIllustratorのモックは2時間くらいかかる。コーディングは2日くらいかかる。10分で作れるのだったら、仕上がりを早い段階で想像できるし、別の案をすぐ試せる。2日かけて作ったものの、やっぱり変だから別のにしようとか思って、さらに2日かけるのでは効率が悪いし、修正コストが高い。

ぼくのサイトでは、トップページと記事ページのレイアウトが異なるので、それぞれの案を考えた。

2. モック作る

次に、Illustrator でモック作る。前は Photoshop で作ってたけど Illustrator に変えた。ラフスケッチでだいたいの構造は決まってるので、それを画面で見た時の見栄えを検証する。雑だけどこれは自分のサイトなのだから自分しか見ないという前提があって、雑でも問題ないということにしてる。8割くらい作り込んだところでやめて、コーディングに入るようにしている。2割くらい変更可能な余地を残しておくことで、コード書くとき融通が効く。

ラフとかモック描かずにコーディング始めることもたまにあるけど、それは余程デザインが頭のなかで固まっている場合に限る。ラフとかモック作るの、コーディングと同じくらい大事だと思ってて、コーディングを始めてしまうとデザインに気を配るのを疎かにしがち。デザインを考えつつ同時にコードを書くというのは結構難しくて、トレーニングが要る。全体のデザイン感を俯瞰できるモックを作っておけば、安心してコーディングできる。

案A

たぶんこれが完成形と一番近いと思うけど、サムネイルの下のキャプションを省いたりしてる。

案B

スライドショーを巨大化したのと、「WORKS」を3カラムにした。3カラム、検討の結果やめることにしたので没になった。レスポンシブデザインにしてスマホで見たとき微妙とかそんなんだったと思う。スライドショー、モックのときは全部の案についてるけど、ブラウザで見たらたいしておもしろくなかったのでコーディング中に消した。

案C

ヘッダを全部画像にするというのも考えた。ヘッダ画像を大きく使うサイトは最近よく見るのだけど、流行ってるからといって採用していいのか、とか、自分を象徴するような写真がそもそも無いとかで、性に合わないから没にした。中央にロゴ置いてあるけどなんで置いたか忘れた。

記事ページ, 固定ページ

あと記事ページと固定ページのモックも作った。こっちはごく一般的な2カラムのブログ形式なので、そこまで変になることもないだろうと思って、ちょっと作って検証するくらいで飽きてやめた。

3. 静的なページを書く

上記のサイト、 Wordpress で作っているので、サイトを作るというのは Wordpress テーマを作るということになるんだけど、Wordpress テーマ作る前に、スタティックな html, CSS ファイルをローカルで作っておいて、その後に各要素を Wordpress のタグに置き換えるという方法で作っている。Tumblr テーマとか作るときも同様の方法で作ってる。

ぼくはモックを別のディスプレイに表示させておいて、それを見ながらコーディングしてる。あくまで「見る」だけで、モックをスライスしてそれを使うということはしてない。このサイトはそもそも画像が必要な箇所がサムネイルくらいだからというのもあるけど、最近はテクスチャをゴリゴリ乗せないデザインが流行ってて(フラットデザインっていうのはバズワードだから個人的には言うの控えている)、だいたい CSS でなんとかなる。こういうサイト作ったときもスライス使わなかった。スライスを使うなということを言ってるんじゃなくて、使う必要を感じなかったので使ってない。必要であれば使うと思う。

モックを CSS に置き換えるという気持ちで書くと、わりと良くて、デザインの妥協点を探しやすいというのがある。モックを完全再現しようとすると、モックではこうなってるけど HTML の構造上ここに置きづらいとかっていうのが出てくる。ぼくはそういうとき構造上妥当なレイアウトにするのを優先するので、完成形がモックと違うレイアウトになっても良いということにしている。position: absolute でめちゃくちゃ頑張ったら再現可能とかもあるけど、トリッキーだからあまりやりたくない。変なことするとあとでメンテナンスしづらい。

今回はトップページ用と記事ページ用の2種類の html, css ファイルを作った。

4. wordpressのタグに置き換える

次に Wordpress の開発環境をローカルで立ち上げて、さっき作った html ファイルを php 化していく。開発環境は Vagrant で、 VCCW っていう便利なものがあるので使ってる。

Wordpress テーマの作り方は体系的に勉強したことがないので詳しく書けることがあまりない。

5. 本番データで調整する

Wordpress には記事インポート/エクスポート機能があるので、本番の記事をローカル環境にインポートすることで、本番の記事データでデザインの調整ができる。ここで大事なのは、モックで想定していなかった記事の書き方をしていた(されていた)ときにスタイルが崩れるかどうか検証すること。一例として下記を挙げる。

  • 記事中の写真がめっちゃでかい時にはみでないかどうか(img.max-width指定してるか)
  • めっちゃ長いURLが書いてあるときにはみ出ないかどうか(word-wrap指定してるか)
  • めっちゃ長い記事タイトルのとき読みづらくないか(記事タイトルのフォントサイズ検証)
  • ページャがない時カラのdivタグができてしまわないか(条件分岐の検証)

max-width とか word-wrap とかはよくあることだけど、このサイトは自分しか記事書かないのだから、自分がまったく想定していない使い方というのは普通しない。このような考え方は、テーマを配布するとかで自分以外の人が使う状況で必要になってくる。実際、ぼくが Tumblr テーマを作るときは、こういう色々な使い方をする人のことを無限に想像して、なるべく崩れることがないように作っている。

だいたい作り終わったら本番のサーバーにアップロードする。

ひとまずめでたい。

6. 改善繰り返す

気づいていないかもしれないけど、リリースした後も修正や改善を繰り返していて、ほぼ毎週どこかちょっとずつ変えてる。上のスクリーンショットも2ヶ月前に撮ったものだから今見るとちょっと違う。

こまめにサイトの様子を見て、気づいた部分は変更していくというのは大事で、放置していると不具合に気づけないし、もっと良い案も出てこない。去年作った同人誌の告知サイト、今見たら Facebook の Like ボタンの仕様が変わっててボタンがちょっとずれてた。こういう外的要因で起こる不具合もあるし、もっと良い言い回しとか、もっと良い構成とか、もっとこうしたいとか、ださいからリニューアルしたいとか、自分のサイト見てるといろいろ思うところがある。高校生のとき自分のホームページ作ってたけど毎月ださいと思ってたから毎月リニューアルしてた。

以上です

サイト作る手順とか方法、自分用なのか、クライアントワークなのか、キャンペーンサイトみたいにリリースしたら終わりなのか、何年も継続的にメンテナンスするのか、お遊びで雑に作るのか、ちゃんと作るのか、とか条件によって作り方がかなり違う。ぼくは個人用サイトはこういうふうに作ったという紹介でした。

Recent Posts

Loading...

3 Notes

  1. sanographix-memo posted this