もともとはプログラマなのだけど、最近、デザインもやるようになった。
いまちょうどiOSアプリを作っていて、デザインとプログラミングの繋ぎこみの部分で得られた知見をメモっておく。
位置指定が面倒
画像やボタンの配置で、「左から3px〜」とか、「左から5%の位置に〜」という指定は、実は面倒くさかった。
グリッド・ガイド
フォトショにはグリッド・ガイドという補助線を引く機能がある。
綺麗なデザインは、「整っている」、つまり「何らかの規則に従って並べられている」という仕組みが大きく寄与しているため、補助線は重要。
自分だけなのかもしれないが、「左から3px〜」とかよりも、「縦軸を10分割して、3番目の線にぴったりくっつける」みたいに引いた補助線を元に指定したいことがある。
（ここではStoryboardは一旦忘れよう）
実例
何を言ってるか分からないと思うので画像で。
これは画面を10分割するようにグリッドを設定しているんだけど、buttonをどの位置に置きたいかと言うと、
- 横は2番目の箱に、buttonの左辺が接するように
- 縦は4番目の箱に、buttonの底辺が接するように
って感じに置きたい。
しかし、プログラマにとっては描画の始点(x, y)だけが重要。
この例だと横軸については、画面幅に対して20%の位置で良いと思う。
let x = self.view.frame.width * 0.2
じゃあ縦軸は？
デザイナが計算してみる。「このbuttonの縦の長さだと、だいたい31%ぐらいの位置に始点がくればいいんかね…？」みたいな。
let y = self.view.frame.height * 0.31
これ、めんどい。
第一に、いちいち計算するのたるい。個数が多いとめんどくさい。
フォトショでグリッドを見たまんま書きたい。
第二に、0.31ならまだしも、0.11455みたいな謎数値は、デザイナとしてメンテナンスしづらい。
複雑怪奇なピクセル指定、パーセント指定がはびこってしまい、デザインを変更したい時にササッと変更するのは至難の技。変更した時に計算が間違っていて、ビミョーにズレてるんだけど気づかない、みたいなことも避けたい。
今の環境で良いのは、自分がデザイナでありプログラマであるので、変更のイテレーションを高速に回せることだと思う。
こうした謎数値は良いことがないので、極力排除していきたい。
解決案
酔ってる頭で見ても分かるように、簡単に指定できるクラスを導入する。
let y = Divider(blockSize: 10, length: viewHeight) // 縦を10分割して、
.boxAt(5) // その5番目の箱の
.bottom(buttonHeight) // 底辺にbuttonがつくような、yの始点
実際にはちょっと違うのだけど、だいたいこんな感じ。
学び
デザイナも保守性に割と気を使っている。
勉強してても、保守性（デザインの変更性）を高めるために、レイヤーの構築方法をくどくど書いてる本に出会ったりする。
みんな気をつけているのだから、保守性を最大化するために、デザイナとプログラマの境界線上のテキトーさを潰す必要があると思った。
デザイナとプログラマ、両方にとって保守しやすいプログラミングというものがある、という知見を得た。
vector画像を使いたい
自分のケースだと、UIに関しては、イラレでできる限りはとにかくイラレ。
なんと言っても、vector画像であれば、@2xとか@3xとか、解像度が上がるたびに画像を作らなくていい。
高解像度の画像の用意
冷静に高解像度の画像の用意を考えてほしい。
10pxの正方形で作ってたのを、20pxで作れと言われる。
でもそれって、元画像の引き伸ばしではなく（つまりギザギザな画像ではなく）、元画像が良い感じに補間された、アップスケール画像を望んでいるわけよね？
フォトショにもそーいう機能あるんだけど、魔法みたいな事が起きるわけじゃない。
まぁそんな事もあろうかと思って、元画像を大きく25px正方形で作ったりする。
でも悲しいかな、時代が進めば、さらなる高解像度を求められる（そろそろ高解像度の戦争は終わったと思いたいが…）。
ビットマップである限り、そうした、「俺、最大どのぐらいの解像度を想定してたらいいんだろう…？」という恐怖から逃れることはできない。
今のXcodeではpdfが使える！！！
Xcode6からは、Asset Catalogでpdf（vector画像）が扱えるようになり、解像度の恐怖から逃れることができる！ 素晴らしい！
@2xどうこう、みたいな世界から切り離される幸せ感、はんぱない。
変更することについての感想
デザインが未熟なので、新しいことを学んだ時に、過去のデザインを見てアチャーってなる。
また追加機能を入れていく内に、だんだんキモくなっていってしまう。
つまり、やっていけばやっていくほど、過去のモノが負債になるのはプログラマー固有の事情じゃない。
プログラマであれば、負債を定期的に解消していきたいムードみたいなのが暗黙の内に現場にあった。
実施できるかどうかは置いといて、負債を解消する気持ち自体は、現場、そして業界全体として許されてたように思う。
デザイナも同じなのだけど、リファクタ期間みたいなのを設けられているのを、あまり見たことがない（バージョンアップによるデザイン変更とかは置いとくとして）。
直すとなるとプログラマも動かす必要があるので大変なのだろうけど、負債を出せない緊張感みたいなのあるんだろうなぁと思った。
自分としては、定期的に負債を返上するように予定を組むようにしている。