エンジニアがデザインに取り組んでわかったこと
最近、いくつかのデザインに取り組んでわかったことがあるので、書いておこうと思う。 ぼくは2,3年前にこの業界に入ってからずーっとフロントの実装畑でやってきた。 それは自分の意図していたものではなかったけど、前職のまぼろしという会社は実装が強みの会社だったので、デザインに触れることはほぼほぼなかった。 それもあってか、ぼくは「もうちょっとコストを考慮してほしい」「このあしらいが一体ユーザーにいくらのお金を落とさせるんだろう」とか、あげくの果てには「実装のことを考えたデザインをすべき」とまで考えていた。これらの考え方はぼくだけでなく、コーダーからよく同様の声が上がっている。 だけどデザイナーさんと接する機会が増えるごとに、デザインができるようになったら今までイラついていたことがどんな風に見えるのか確かめたいな、という気持ちになった。 それ以外にも「なにか作るとデザイナーばかり褒められて厳しい」
不特定多数の人が更新する大規模サイトに必要な CSS 設計の思想
今話題（？）の CSS 設計のメモ。 この「ある程度の規模」というのは、肌感覚としてテンプレートの枚数( ≠ Webサイトのページ総数)が 20P〜50P くらいのイメージ。 また、コーディング完了後に自分以外の人間による断続的な更新が入るという前提。 そして一番重要なのは「更新する人のスキルは定義しない。」ということ。つまり HTML の知識が乏しい人が更新する可能性があることを前提とする。 きっと1ヶ月くらいすれば変わると思うけど、自分の思想のログとして残しておく。 今ぼくは以下のことに気をつけながら CSS を書いている。 コードが長くなることを気にしない セレクタが長くなることを気にしない セマンティクスの実現の難しさを理解し、妥協する 再利用性より保守性 拡張しやすい設計 最初から最適化しようとしない ゴールは目先のパフォーマンス向上ではなく誰が触っても問題が起きにくい設計 ひと
「コード汚くてもデザインが見えればいいじゃん」への返答
なぜコードが綺麗じゃないといけないの？という質問をごく一部の方、特にデザイナーさんから受けることがあるので（半分くらいの人はネタで言ってますが）、自分なりの意見をまとめたいと思う。勉強不足で浅い感あるので、偉い人にご指摘いただけると嬉しいです。 「コード汚くてもデザインが見えればいいじゃん」の定義について 「コード汚くてもデザインが見えればいいじゃん」はかなりふわっとした印象を持つので、ここでは「コードが汚い」の定義として、以下の2つを挙げる。 メンテナンス性に欠ける （W3Cの）仕様に沿っていない なので「コード汚くてもデザインが見えればいいじゃん」というのを「メンテナンス性に欠け、仕様に沿っていなくても、デザインが見えていればいいじゃん」という意味に置き換えて話を進める。 確かに表面的な視点で見ると、エンドユーザーには関係がなさそうに見えるかもしれない。 例えばメンテナンス性の高いコー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
