7月7日ってことで、iOS 7 のこと
珍しく文章を書く意欲が出る期間に突入してる感じがしているので、色々書く練習も兼ねて軽いことでも書くようにしていこうかなあと思う。
で、奇しくも7月7日ってことで、ちょっと話題の旬は過ぎたけど、iOS 7 のこと。自分で触ったことはない。色んな意味で気になりすぎてデベロッパー課金しようかなあと思ったけどしてない。触ったこともないのに評価を下すべきではないので、アレはイケてるとかイケてないとかそういうことを言うつもりはないのだが、触ったことがなくてデベロッパー登録してないからこそ、NDAとか気にしないで色々言えるというメリット(? もありそうってことで、今気になってることを書いておこうと思う。後にそれを自分で読んでどう思うのかなあっていうのも気になる。
iOS 7 ってアレでしょ?
(映画 『アバター』 より)
スクリーンの中に深度のある擬似空間とレイヤー構造を作った、ってことでこれどういう世界観なのかなあと考えて、思い浮かべたのがコレ。映画とかでよく見る、空中にタッチインターフェイスのついた複数のスクリーンを映し出し、ひょいひょいのひょいと指先で操作できるアレ。
iOS 7 ではこの世界をiPhoneの筐体のスクリーンの向こう側に作り出した。今は技術的な限界で筐体の中でしか実現できないけど、いずれこの世界観は筐体の中を飛び出して、実世界空間の中でこのOSの操作が実現できるはず。空間の中に現れる平面スクリーンなので、そのレイヤー自体に奥行きがある表現を加えるのはおかしい、だからそのレイヤーの中身は徹底してz軸を排除したフラットUI。
っていう邪推が正しいのかどうかわからないけど、自分的にはそう考えた時にあの落とし込みに対して納得が行った。
デザイナーズマンションみたいな感じ
iOS 7 のグラフィック表現は、モダニズム的なミニマルな表現に寄っている。立体空間に例えるならモダンなデザイナーズマンションのような感じに似てる。アレね、アレも住んだことないから知らないけど、まあおそらくイイカンジに住むの難しいんですよ。もうオシャレで教養のある人しかうまく住めない。似合う家具は限られる。いつも掃除してないといけない。モノ置き過ぎても台無し。シンプルだから懐が深いかというとそうでもなくて、逆にあの手のミニマリズムはすごく制約が厳しいし、シンプルで計算されているがゆえに空間の中でそれが主役のような存在感を発揮する。自らのオシャレの成立のために周囲の全てが存在するような、わりとそういう緊張感のある振る舞いを周囲に強いる感じの性質がある。逆に言えば、その空間に置いたら空間ごと台無しにしかねないものが世の中にたくさんあり、台無しビリティが非常に高い。
OSは色んなアプリを包括するプラットフォームなので、主役はどっちかというとサードパーティのアプリやコンテンツという認識でいるのだけど、アレで行くとOSのデザインが、アプリやコンテンツのデザインにかなり影響を与えそうで、それが吉と出るのか凶と出るのかわからない。みんながみんな、オシャレなデザイナーズマンションに住むことを好まないように、どのアプリもああいう感じのデザインになるというのはちょっと考えにくいのだけど、デザイナーズマンションに仏壇置いたら変なように、あのUIと違和感なく共存できるアプリやコンテンツが割と多くはなさそうな感じが気になる。
メタファーは古いものへの歩み寄り
iOS 7 の発表をタイムライン越しに見てて、何人かの人が「自分の親には勧めにくくなった」と言ってたのが印象的だった。ミニマルな表現は割とどんな分野でも受け手に深いレベルの理解を強いる。
行き過ぎたスキューモが無意味だよねっていうのは共感する。これまでのiOSの、「え、それ、そこ皮テクスチャじゃなくてもよくね?」みたいなのはすごくあるんだけど、今までのリアルでの習慣をなぞって、似たような見た目をスクリーンの中で再現する(紙に似た使い方をするものには、紙に似た表現を使うとか、押すべきところにはボタンっぽい凹凸を施すみたいなの)というアプローチは、やはりそれなりの効果があり、iPhoneがここまで多くの人に使われた一因にはなってたのだろうなと思う。
スキューモフィズムや各種のメタファーが醸成するアナロジーは、深く理解していないユーザーに対する思いやりであり歩み寄りだ。今まで慣れ親しんだアレと同じようにすれば、「とりあえず使える」。対象に対する本質的な理解や、慣れ親しみがなくても、とりあえず今までの経験をなぞればいいようになっている。
電子メール、電子書籍、電子マネー…どれもスキューモ的なネーミングだと思う。初めて新しい手段に接する人に対しては、今までの習慣をメタファーにして表現することでしか、うまい説明ができない。そして未だに、それらの表現が幅をきかせてる。(新しい概念が新しい言葉として広く定着したのはググるとか、ツイートするとかぐらいしか思いつくものがない。あ、マイミクとかもそうかな。)電子メールも従来の手紙とはだいぶできることが異なるし、電子書籍、電子マネーもそうだ。これらの古くさい呼び方、表現が新しい概念の新しい可能性を阻害している一面があることも否めないけれども、結局そういった表現が、今の時代に新しい概念を「広める」には一番効率がいいってことで、今の現状があるのだろう。
そういう時代なのかもしれない
そんなわけで、今までに見聞きした情報の範囲内で本音を言うと、「理念はわかるけれど、ちょっと早くないっすかね・・・?」っていうのが正直な感想になってしまう。いや、Disってるわけではなくて、逆にむしろそういう感想しか持てなかった自分自身が割と残念で老害感あってかなしい。
一方で、タッチインターフェイスはもう導入〜普及フェーズを過ぎて、これからはそれを日常の中に当たり前に存在するものとして発展させていく時期だという見解がしかるところにあって、だからもう変なメタファーいらんだろっていうことになって、回りまわって結果的にわーいフラットUI、フラットUIみたいな流れになってるんだろうねえっていうのも理解はできる。いずれにしても、Windowsしかり、Google、Androidしかり、この時期に色んな所から似たようなアプローチが出てくるというのは、深い意味がありそうだ。プラットフォーマーではないいち小作農としては、うだうだ言ってないでこの流れにどううまいこと乗ってくか、しかないよなあ。
そもそも、iPhoneが出た時も割と初期に入手したのだけども、その時も「自分は好きだしスゴイと思うけど、これ普及すんのかねえ?」っていう感想だったので、自分のこの手の感覚はまるで信用出来ない。
いやー、どうなるのかねえ。とりあえず iOS 7 がとても気になってしまう今日このごろです。
# 追記 1
パルスのファルシのルシがパージでコクーン…???とか CUI(黒い画面)が怖い…とかも、アナロジー不足による親しみ辛さという点では似たような感じがある事例かも、と思った。
# 追記 2
TwitterやGoogleが新しい動詞を生んだのに対し、Facebookはあれだけ普及してるにもかかわらず(だからこそ?)、言葉の表現に関しては割と保守的な感じを受けるのがなんか面白いと思った。
他人の「制約」を知るのは結構面白い
エンジニアが作るネットサービスのアイデアがしょぼいワケ【連載:えふしん】 - エンジニアtype
これ読んだのをきっかけに思った、というか、えふしんさんの書いてらっしゃることとはだいぶズレる内容なので、結局あんまり関係ないんだけど。
エンジニアさんだけではなくて、営業さんとかお客さんとかでもみんなそうなんだけど、自分と違う職域の人と一緒に何かを作っていると、やっぱりそれぞれの立場に応じた発想の「制約」があることに気づく。で、その他人の発想の「制約」を知るという作業が、自分は結構好き。
発想の制約というのは基本、何か理由がないと生まれないわけで、よくよく話を聞いて考えてみると非常に理にかなっていてよくできた必然であることも多い。例えば、エンジニアさんがあまり良い反応をしないようなシステム的に嫌な負荷がかかるUIや仕様は、よくよく考えると人間(ユーザー)にとっても実はあまりメリットがない体験である事も多くて、エンジニアさん達の考え方を受けて考えなおすと、より良いもの(ユーザーもうれしいし、システム的にもイケてるもの)になったりすることがたびたびあって、そういうのはすごく面白い。自分もまたデザイナー特有の発想の制約(一般化は好きじゃないけど・・・)に囚われながら何かを考えたりするんだけど、それが全く違う考え方をする人の制約を取り入れることで、自分の発想にはない、より良い「必然」に辿り着ける可能性があるなあと思う。そういうのが、自分と違う職域の人と何かを作る面白さだと思う。
もちろん、他人の発想の制約について知るときには、相手の考えに対してそれは「なぜ?」と思ったらその都度突っ込んで聞くようにしないといけないし、相手が、なぜ、どういう目的で、どういう背景で、どういう思想や習慣で、そう考えているのかということを自分にも理解できるように説明してくれるのが前提になる(他のイケてるサービスがこうしてるから、誰々がこう言ってたから…とかじゃなくてね)。
もちろん単純に、目的に対して邪魔になっていて無理してでも取っ払った方がよいような制約もあるし、この制約がちゃんと目的に対して意味を持ちうるものなのかどうか?「必然」に化けるかどうか? イケてる「制約」を見定める選球眼みたいなのを磨くのが重要なのだろう。
自由度高すぎるゲームとかが必ずしも面白くないように、制約が全くない世界もまたつまらない。「制約」を「必然」に変えるような感じの作業ができた時は結構うれしい。
# (追記)
で、もちろんのこと自分が何かする時も、その理由を他の人にもわかるようにちゃんと説明しないといけない。その作業をすると、自分の中でなんとなくやってる感じのことが減って、色々整理されて筋道が立つし、それを受けてもっと良いアイデアが他の人にもらえることもあってとても良い。
Gitで数個前のcommitを遡って分割する
数個前のcommitを遡って、それを分解して2つのcommitに分けたいとか、たまにある。
例えば、git log
で上から遡って5つ目のcommitを2つに分けたい場合
git-rebase -i で5個目のcommitを
$ git rebase -i HEAD~5
edit
に変えるで、git-rebase -i した状態で、HEADの位置をさらに一つ手前のcommitに移動する
pick xxxxxx Add JS files
pick xxxxxx Move Vendors CSS files
pick xxxxxx Add jquery.powertip
pick xxxxxx Add font
edit xxxxxx Design for tasks#index ← 分割したいcommitの 'pick' を 'edit'に変える
すると、分割したいcommitの中のファイルがUnstageされる
$ git reset HEAD~
分けたい部分を別々にaddしてcommitし直す
Unstaged changes after reset:
M app/assets/stylesheets/screen.css.sass
M app/views/tasks/index.html.haml
とかやって、2つのcommitができたら、普通に
$ git add app/assets/stylesheets/screen.css.sass
$ git commit -m 'Sass for tasks#index'
$ git add app/views/tasks/index.html.haml
$ git commit -m 'Markup for tasks#index'
すると、普通にrebaseが成功して、commitが遡って分割できる。めでたいヾ(*'ω'*)ノ゙
$ git rebase --continue
第24回 デザイナー向けプログラム部 #p4d に行ってきた
http://connpass.com/event/2748/
やったこと
前回の続き
何とかタルトラッカーのような、アレをもっと簡素化した、気軽にポイント管理ができる感じのタスク管理サービスをRailsで作ってて、それの続き。
TaskをIterationに条件付き has_many するのをやめて、task の status が変更された時だけIterationに紐付けることにした
/app/models/iteration.rb
としていたのをやめて
has_many :tasks, :conditions => { :status => 'done' }
だけにする
has_many :tasks
Iteration にデータをどうやって入れるか?
Iteration は以下の2カラムをもってる
- start_date 毎週月曜日はじまり
- end_date 毎週日曜日おわり
→どうやってデータを入れておくか? cronで毎月未来1ヶ月ぶんまで作るのがいいのではということになった。Heroku、cronお金かかるのかと思ってたらタダらしい。今回は間に合わなかったので次回以降に
今週の(今日を含む)Iterationを作ってみる
start_date は今日を含む週の最初の日
end_date は今日を含む週の最後の日
これが、こう書ける。
i = Iteration.new
i.start_date = Time.now.in_time_zone.beginning_of_week.to_date
i.end_date = Time.now.in_time_zone.end_of_week.to_date
今日doneになったTaskが紐づくIteration = 今週の始まりの日が start_date と 一致するIteration
Iteration.where(start_date: Time.now.in_time_zone.beginning_of_week.to_date).first
tasks#index に 今週の始まりの日がstart_dateと一致しているIterationをTaskに紐付ける @this_iteration メソッドを追加する
参考)
http://guides.rubyonrails.org/active_record_querying.html
2.3.1 Equality Conditions
app/controllers/tasks_controller.rb の def index に @this_iteration を追加
def index
・
・
・
@this_iteration = Iteration.where(start_date: Time.now.in_time_zone.beginning_of_week.to_date).first
task の status を 'doing' にするボタンにhidden_field で Iteration を紐付ける処理を追加する
app/view/tasks.html.haml
- if task.status == 'doing'
%span.status<>
= form_for(task) do |f|
・
・
= f.hidden_field :iteration_id, value: @this_iteration.id
= f.button "#{content_tag(:i, '', class: 'icon-ok-sign')}DONE".html_safe, type: :submit
doing 以外の status 変更ボタンには iteration を nil にリセットする処理を追加する
- if task.status == 'done'
%span.status<>
= form_for(task) do |f|
・
・
= f.hidden_field :iteration_id, value: nil
= f.button "#{content_tag(:i, '', class: 'icon-ok-sign')}DONE".html_safe, type: :submit
Routingにdone のアクションを追加する
参考)
http://guides.rubyonrails.org/routing.html
10.2 Adding More RESTful Actions
/photos/2/preview/ みたいな処理のときには 'member'
resources :photos do
member do
get 'preview'
end
end
/photos/search/ みたいな時は 'collection'
resources :photos do
collection do
get 'search'
end
end
今回の、this_iterationメソッドは前者に該当
config/routes.rb にこんな感じで追加する
'done' オブジェクトが新規に生成されるイメージなので post で
resources :tasks do
member do
post 'done'
end
end
で、done とかを メソッドにしちゃったほうがもっとカッコイイよということで
app/controllers/tasks_controller.rb に def done を追加
def done do
member do
post @this_iteration
end
end
とすると、done 以外の status 変更 もメソッド化する必要がある
とかやっとく。(ここでタイムアップ・・・次回につづく)
def start do
member do
delete @this_iteration
end
end
以下、他にも色々教わった。
コンソールにデータをリロード
reload!
タイムゾーンで日時をパースする
i.start_date = Time.zone.parse('2013-07-01')
データベースをリセットして作りなおす
rake db:reset
rake db:setup
rake db:migrate
データベースを全部表示
Iteration.all
Iterationの1件目を削除
Iteration.find(1).destroy
DBを直接見る
$ rails db
SQLite version 3.7.12 2012-04-03 19:43:07
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> SELECT "iterations".* FROM "iterations" WHERE "iterations"."start_date" = '2013-07-01' LIMIT 1;
sqlite> SELECT "iterations".* FROM "iterations" WHERE "iterations"."start_date" = '2013-07-01';
sqlite> SELECT "iterations".* FROM "iterations" ;
2|2013-07-01 00:00:00.000000|2013-07-07 23:59:59.999999|2013-07-04 11:30:13.748625|2013-07-04 11:30:13.748625
日付以外の時間とかもDBに入ってしまっていたので、日付だけに直す
i.start_date = i.start_date.to_date
例えば、Date.today のmethodsはこんな感じで確認することができる
なんか色々できる。クォーターとかもあるのかー。すごいなー。
Date.today.methods.grep /beginning/
=> [:beginning_of_day, :at_beginning_of_day, :beginning_of_week, :at_beginning_of_week, :beginning_of_month, :at_beginning_of_month, :beginning_of_quarter, :at_beginning_of_quarter, :beginning_of_year, :at_beginning_of_year]
Date.today.methods.grep /end/
=> [:end_of_day, :end_of_week, :at_end_of_week, :end_of_month, :at_end_of_month, :end_of_quarter, :at_end_of_quarter, :end_of_year, :at_end_of_year, :require_dependency, :load_dependency, :send, :public_send, :extend, :__send__]
Railsのデバッグ方法
とか書いておくとログに this_iteration の中身が出る
p @this_iteration
とかやっておくとどこにデバッグ出てるか見やすくなって便利(ΦωΦ)
puts "========================"
p @this_iteration
puts "========================"
Routes の確認
とやると
$ rake routes
これが見れる
done_task POST /tasks/:id/done(.:format) tasks#done
tasks GET /tasks(.:format) tasks#index
POST /tasks(.:format) tasks#create
new_task GET /tasks/new(.:format) tasks#new
edit_task GET /tasks/:id/edit(.:format) tasks#edit
task GET /tasks/:id(.:format) tasks#show
PUT /tasks/:id(.:format) tasks#update
DELETE /tasks/:id(.:format) tasks#destroy
root / tasks#index
感想
- またもや、@satococoaさんにすごくわかりやすく教えていただき、ありがとうございました。また教えてもらうだけになってしまった。。また@satococoaさんが何かを作る時にはお手伝いしなければならない感じある(ΦωΦ)
- 色々教えていただいたけど、Blogに書こうと思ってひと通り復習したら結構忘れてたりあやふやだったりして調べなおしたり考えなおしたり。。とりあえずざっくりでもBlogに書くのは有効だ。こんなの誰が見ても役に立たないかもしれないが、少なくとも自分にとっては書くだけで役に立つのだ。
- ソースがひと通りGitHubに挙げてあるので、教えて下さる方の@satococoaさんもご自分のMacにcloneして、手元のものを見ながら、色々素振りなどをしながら教えていただくことができた。あの方法は良い。
- 教えていただく際に、@satococoaさんにサービス使ってもらったら、UIのわかりづらい場所がわかったのでこう直したらもっと良いというアイデアを思いついた。人に使ってもらうのは良いな。
- いつもForkwellの方にしか行ってなかったが、初めて万葉さんの方におじゃました。一度行ってみたいと思ってて、やっとおじゃますることができたヾ(*'ω'*)ノ゙
- ちょうど @a_matsuda さんが @machida さんに会いたがってた(何かを頼みたがってた)ので、飛び入りでお連れした。P4Dに@a_matsudaさんがいる絵はなんか新鮮でよい。
- 連れて行っていただいた中華屋さんが美味しかった。杏仁豆腐がうまい。そしてみんなずっとファミコンの話してた。
- そんなわけで、やっぱりRailsは楽しい…のだが、やっぱりたまりにたまったタスクを片付けるまで or 次回のP4Dまで封印しておこう・・・(ΦωΦ)
モリサワ タイプデザインコンペティション特別セミナー「タイプデザイナーの視点」に行ってきた
タイプデザインコンペティション特別セミナー「タイプデザイナーの視点」開催のお知らせ
最近は、P4D関連とかRuby関連とか、技術寄りのイベント参加が多くて、デザイナー向けのイベント(しかも偉大なタイプデザイナー様…自分にとっては神様みたいな雲の上の存在…)というのは緊張したが、とてもとてもおもしろくて、本当に行ってよかったです。興奮がさめないうちにメモを整理(ΦωΦ)
講演内容
- マシュー・カーター氏「欧文のテキスト書体とディスプレイ書体」
- 岡野邦彦氏「和蘭(わらん)ができるまで。」(和蘭:モリサワタイプデザインコンペティション 2012 和文部門 金賞)
- 小塚昌彦氏「ひらがなを考えよう」
の豪華布陣
以下、内容のメモ(ところどころ聴き逃して内容が不正確だったりします。あと遅刻したのでマシュー・カーター氏の序盤を聴き逃してしまった…モッタイナイ…)
マシュー・カーター氏「欧文のテキスト書体とディスプレイ書体」
Millar daily Roman
Vincent for Newsweek
- 新聞のために作った書体
- 題字や本文テキスト、黒字に白抜きで利用する用などいくつものパターンを作った
Monotype Bembo Roman
Verdana
- スクリーンで読まれる事に最適化して作った
- IKEAのパンフレットに採用された
- スクリーン用のフォントを紙媒体に使うなんて!…とデザイナー達にDISられた
- が、私は良いと思う
- 書体の出自が何であろうと、かっこ良ければそれでいいんだよ
Yale typeface
- イエール大学のための書体
- 大きいサイズで表示したり、スクリーンで使われる事を考慮
- 構内のゴミ箱にも使われててうれしい
monticello(モンティチェロ)
- 活版用タイプフェイス
- ミラー(左右反転)でスケッチを作る
活版のタイプフェイスは直線的すぎる- イタリックfとかの曲線が不恰好
- 写植になって改善
- 3Dから2Dになり技術の進歩で精密なフォルムが作りやすくなった
- デジタル時代になってから知らない人にものすごい雑に
コピーデジタル化された - 手書きの味わいをだすために自らリデザイン
- 縦と横のラインの接合部を盛る
- 横のラインにボリューム出し
- 書体をチョコレートに漬けた感じのボリュームを付加(これは逆、説もあり。自分は正と解釈した…が記憶に自信がない)
- 活版用のタイプフェイスをそのままデジタルに変換しても同じパフォーマンスは出ない
岡野邦彦氏「和蘭(わらん)ができるまで。」
フォントデザイナーを志すきっかけ
- 93年、マシュー・カーター氏のワークショップ
- sophiaを使って作られたパンフの美しさに感動
- フォントにもデザイナーがいる!という意識の目覚め
オランダ ハーグに留学 書体デザイン学ぶ
- オランダは美術館が専用の制定書体を持っていることが多い
- エッシャー美術館とか
- マウリッツハウス
- 専用のフォントは8カ国分用意される
- 日本語用のフォントはないのでパンフがすごく残念な感じに!
和文書体について
フォント制作の過程
- 200-300dpiでスケッチをスキャン
- Illustratorでトレースし作りこむ
- Glyphsでフォント化
- OTFに
- Illustratorで実際に打ってみて、またフォントから直してをくりかえす
- 出力チェックは未アウトライン状態でずっとやっていたがアウトライン化すると出力でフォントが太くなる事を思い出してアウトライン化した状態に合わせて全部直した
- アウトライン化してから出力チェックした方がいい
- 最近はリガチャーの要望も多いので、OpenTypeFeature のあるフォント作成ソフトがおすすめ(Glyphsはついてる)
クルマのデザインが書体デザインのヒントになった
- 横方向の流れ
- 下半身の重心
和蘭という書体名に込めた思い
- オランダでの経験
- オランダの低地と、書体の重心の低さをかける
- 蘭の小振りな花びらのイメージ
- 江戸時代の出島(唯一オランダとのみ貿易)
- 日本と世界をつなぐ架け橋になってほしい
小塚昌彦氏「ひらがなを考えよう」
縦書きの草書
- 傾きに注目する
- かな文字は1字1字は独立して見ない
- 1ワードが一続きでつながっている
- 「わ」右下がり
かな文字のスケッチ
- かな文字は筆を使って水彩のビリジアンを薄く溶いてスケッチ
- 鉛筆はつかわない
戦後の話
- カタカナ小さいのが多い
- いかにカタカナを大きくするかの流れが昭和20-30年代
- タイポス37 昭和34年
- 新書体ブームへ
- FrutigerやHelveticaのようなファミリーつくりたい
- かなを分解してそれぞれのエレメントをパターン化するという考え方
- 写植の時代へ
かな文字作りについての認識
- ひらがなの「は」は 「波」の草書体から生まれた
- 左側の縦棒はさんずいを象形化したもの
- ひらがなも漢字もエレメントのパターンを組み合わせて作ると認識してるかもしれないが、かなはその発想でいいのか?
- 漢字は表意文字だが、ひらがなは音声そのもの
- 日本語は表意と表音が混じり合ってる特殊な言語
『新書体』という本、 桑山弥三郎氏編集
- デザイナー30人が参加
- ほとんどがパターン化の発想で作られてる
例えば機械の読み上げ音声を例に考える
- あきはばらは「あ」、「き」、「は」、「ば」、「ら」
- ではなく 「あきはばら」と1ワード一続きで発音しないと変
- カナをパターンの組み合わせで考えることは、読み上げ音声の違和感と同じ感じがある
- ひらがなは出自から縦組み用に作られてる
書体における線
- のっぺりした単調な線ははじまりと終わりがない
- セリフの発生→線にはじめとおわりの区切りが欲しい
- ディスプレイ体は面の発想
- 横線を宙に指で書いてみて下さい
- 左から右に書くよね?右から左に書いた人いないよね?
- 漢字は右手でかかれたもの
- 石に文字を掘っていた時代、線のはじめとおわりは意識されなかった
- 紙と筆記具が使われるようになってはじめて、線のはじめとおわりが意識されるようになった
書体に制作において考慮するデザイン要素
- ウエイト
- 重心
- ふところ
- 地球に重力があるから、重心は下よりのほうがカッコイイ
- 宇宙に行って無重力状態になれば、上重心の書体がカッコよくなるかも?
かなのエレメントの出自
- 「に」「ほ」の左の縦棒は にんべんを象形化したもの
- 「は」 さんずいを象形化したもの
- 似ているが出自が全く違う物を同じように表現していいのか?
- 似たようなものは単純化パターン化するのがタイポスの考え方だがそれでいいのか?
かなは発音すると全部違う音であるように、現代において当たり前になったパターン化、画一化に対してもっと懐疑的になっていい
文字とは
- 文字は目で見る言葉である
- 文字の形は右手の軌跡である
- タイポグラフィは民族のもの
陸隷書という書体(モリサワ)
- 中国の作者にかな文字を追加で作ってもらった
- かなの来歴を説明
- 作者納得しない
- 「あ」隷書にテールをくるっとはらうパターンはないと抵抗
- 外国の方に無理言って作ってもらって申し訳なかった・・・
活版の種字
- 正確な作り込み難しい
- 活字の母型の深さが不揃いだと刷りの太さにむらが出る
活版書体を縦組みで美しくみせるために傾きを調整
- 「ね」「な 」前のめりに傾かせる
- 「る」 中心より左寄りに置く
- こうした調整ができないのが鉛の活字の限界だった
横組を意識して運筆方向を決める
- 50音中14字は左下方向のはらい (一番多い)
- 終筆のハネはじゃまなときがある
- 横組には横組の作り方がある
タイプフェイスの機能
- 一列にならぶこと: alignment
- 情報を正確に伝達する: text
- 視覚的イメージを表現: display
質疑応答
Q: 文字デザインのデジタル化の影響についてどう思われますか?
カーター氏
小塚氏
- 原点はかわらない
- 読者が気づかないように旧来のものを現代の技術で再現し、技術を生かして今までにできなかった事を表現するのが現状
- 写植もデジタルも転換期は重鎮にDISられる
- これから画期的にタイポグラフィは変わる
- 日本語にはプロポーショナルな書体がない
- 欧文のハイフネーションのような発想も必要
岡野氏
- 自分が新しいんじゃないかと思ったアイデアが、金属活字の時代にも行われていたりする
- 古いものに学びつつ、新しい事にチャレンジ
- 使い方によって文字の形も動的に変化していいのでは
Q (カーター氏へ)かな文字はワードごとの固まりでとらえるという小塚氏の話をうけて、欧文書体の組版ではどうお考えですか?
- 欧文では、文字は組み合わせる事でしか意味をもたない
- 可読性が最重要
- それぞれの文字を単体で見せるのに注力するのは本末転倒
- 文字そのものには意味がないから
- 文字同士のスペーシングが最大の意味を持つ
Q 文字に興味をもったきっかけは?
カーター氏
- 父がタイポグラファーだった
- オランダのタイプ鋳造所で働いた
- デザインより前に活版作りから学んだ
- 見習いからデザインをはじめた
小塚氏
岡野氏
- 学校の課題で毎週ポスターを作る
- 文字を使うには見本帳を繰って選ぶ→イメージにあうものがない!
- 写真は自分で撮り、イラストも自分で書くのに…文字だけは他人の作ったものを使うのに疑問
- 自分で作ろう
Q カッコよさとユニバーサルデザイン・視認性への配慮の両立にジレンマ。乗り越えるこつは?
小塚氏
- 大きくすれば見える。大きくすれば情報は減る
- 専用のフォントを作るには資本がいる。デザインだけの問題ではなく社会のバックアップが必要。
感想
- タイプデザイナーはやっぱり偉大だった…!
- 自分にはとてもなれそうにない…
- でも作ってみたいのでGlyphs買おう(ΦωΦ)
- かっこ良ければいいんだよ、っていうのがいいよね!(IKEAの話とか)
- マシュー・カーター氏のセリフ、ホント美しい!
- 岡野氏、初めての和文書体製作であのクオリティすごい!そして直し続ける執念、情熱、ただひたすら頭が下がる。自分には真似できそうにない。
- 和蘭のビジョンもすごく良いと思った。従属欧文に対する問題意識。普段のデザインワークの中でのモヤモヤを解決するために生まれたものっていうのもいい。
- 小塚氏のお話はすごく本質に迫ってて、モダニズム以降の流れに今一度懐疑的になって新しい価値を生み出せという、現代のデザイナーへの応援メッセージに思えた。今は歴史の転換期なのだなと改めて感じて胸熱。
- 遅刻して一番端っこの後ろの席だったせいで、前の席に岡野氏、隣にマシュー・カーター氏…というおいしいポジションに…(ΦωΦ) ファーー!となった
- 当然なんだけど、タイプデザイナーの方々はみんな「フォント」って呼ばずに、「書体」「タイプフェイス」って呼ぶ。それがいいよね。
- あと、岡野さんの話でも10年かけて作るって、和文書体ってやっぱり大変だよなあ…我々は使う側だからそれを気軽に選んだり、上から目線で褒めたりDISったり…ホント気楽なもんですよ…(すいません…
雑談 with @machida, @saucerjp
このあと、一緒に来てたデザイナー友達と、デザインについてすごい話してすごい楽しかった。デザイナーどうしでデザインについてまじめにこんなに話すのはすごく久しぶりで(プログラマとシステムについて話すことは多いのに…)、やっぱり自分はデザインが好きだなあと思った。
色んな話をしたのだけど、この2つが特に自分的に印象的。
デザイナーのコアスキルは何だろうね?
理屈は後付けだよね?
- デザイナーは感覚的なものが先に来て、後でその理由を言語化して納得して確信を得る(もしくは人に説明するための手段を得る)
- というか、感覚的にモヤっときてるものの背後には必ず、確固とした理由があるので、それを後から言語化するのはそんなに困難ではない。
- ところが人に説明するときには、理屈で説明するしかないので、まず理屈から入ってデザインしたんだなと思われがちなんだけど、割とそれ、実態とは違うよね。。
- 結局、自分で作る中で、感覚と審美眼を磨くしかないんだよなー。
的な話をしてて、書いてたらこんな時間だ…!!
仕事中に抜け出させてもらって行ってきたので、これから仕事します・・・・すみません。。。
いやー、デザインって(つらいけど)楽しいですね。いいものですね。
追記
読んだ方からフィードバックいただきました。ところどころ間違ってたみたいだ。すいません・・・
ご指摘、ありがとうございました。
「デジタルになってから知らない人にものすごい雑にコピーされた」
→ これって、おそらく、許可のない「コピー」ではなく、マシューさん自身が最初のデジタル化に関与しなかっただけではないかと思います。そのデジタル化はあまり良くなかった。
→Monticelloを出すことのできる正当な会社によるデジタル化が、例に出されてあれだったのか100%確かではないので、「コピー」ではなく、「デジタル化」とかに変えれば問題ないかと。
「書体をチョコレートに漬けた感じのボリュームを付加」
→ これは逆です。「そうではない」と言っていました。チョコレートを付けたように全体を太くするのではなく、例えば、ステム(縦画)はやや太くするくらいに、セリフ(横画)の太さはそれよりももっとウェイトを強めた、という感じだったはず。
→ もちろん、「ステム=縦画」、「セリフ=横画」の意味ではありません。あの例のなかで、縦画のうち、例えばステム、太くした横画のうち、例えばセリフ、という意味です。
「活版のタイプフェイスは直線的すぎる」
→ これって言ってましたっけ? 機械の制約のせいで、イタリックのfが途中で切れた感じで、しかもほかの文字よりも角度が直角に近くなってしまったというようなことは言っていたと思いますけど。
Vincentのところに、「新聞のために作った書体」って書いてありますけど、「雑誌」ですよね。
Verdanaの綴り、間違ってる。
第23回 デザイナー向けプログラム部 #p4d に参加しました
http://connpass.com/event/2639/
前々回のP4Dから作り始めたRailsアプリがあるので、それを進めたく参加。
既存のModelをhas_manyしてるModelを作りたかったのだけど、Rails Guides とか見て1人でやってみたんだけど詰んだので、教えていただいた。
色々わかったこととかやったこととか
- イチからやり方聞いてどうしたらいいんですかー、ってなりがちなんだけどそれよくない。やってみてわからなかったことをはっきりさせて、わからない部分だけきくのがよいと思った。
- 自分がわからないこと聞くだけで、デザイン知りたくて来てるエンジニアさんもいるのにあまりフィードバックできず申し訳なかった。ので、せめてわしが答えられる事を…と思い帰ってから急いで駄エントリ書いたらまさかの800ブクマ超えでびびった。
- モデリング、色んなやり方が考えられるが、今回のケースの場合は中間テーブルをもたせず、特定のカラムが特定の値だったものだけ紐付けるという条件付きhas_manyをやるのがいいと教わった。ググってみたらなんかわかったような気がしたので今度やってみよう。
- データベース設計は難しい。。
- Rails3 レシピブック便利。何か具体的な方法を知りたくなったら見るべし。
- 毎週月曜日始まり日曜終わりでstart_dateとend_dateを持つテーブルがあるのだけど、どうやってデータを作るべきか。(そのデータはある程度未来のぶんまで必要である)
- 何か別のユーザーアクションをトリガにしてデータを作るのも良いけどおそらく色んな矛盾が出る。
- crontab回すほどのことでもない
- イケてないけど、カレンダー見ながら最初にある程度の未来まで手入力でデータを入れておけば、とりあえずそれで良さげということになった。動くのが正義だ!
- わからないことググってコピペ駆動でやってると、やはり限界が生じる。どうしたらいいか。
- Rails Tutorial をやるのがよい。MVCの基本的なことも結構書いてある。日本語版も作ってくださっているし、英語の勉強がてら英語でやってみてもいいかも。
- Ruby on Rails Guides をちゃんとイチから読むのもよさそげ
- (Rails 頻繁に色々変わるので、本とかよりも公式に近いドキュメントを見る方が良さそう)
- 何かどこかで変なことやってるらしくて、Herokuにpushする前に、なぜかいちいちassets:precompile しないとassetsの変更がHerokuに反映されない問題がありめんどい
- ローカルのprecompile されたassets を一度クリーンするとHerokuが勝手にコンパイルするようになるっぽい
- Gitでデザインのcommit、どのくらい分けてる?って聞かれたので以下のように答えた
- デザインは割とページ単位(というか一つのviewファイル単位)で考えていて、1view内のデザインをイチからガッツリ作ったときは特に細かく分けない傾向にある。
- Viewのマークアップと、SassとかのCSSは、"Markup for hoge#index" "Sass for hoge#index" みたいにしてcommitを分けてる。(後でSassだけ別branchにcherry-pickとかすることが多いので)
- あと、commitわけても、デザイン部分は誰もコードレビューしてくれない・・・
- 逆にViewにロジック入れてたり、Controllerを少しいじったり、JSやCoffeeScriptでなんかした場合は、レビューする人が見やすそうな範囲でcommit分けるようにしてる
- 後から部分的にデザイン修正した場合は、できるだけ分割して、後から何を変えたかわかるようにしている…(が、細かすぎる変更をちょこちょこ色々やった場合は Fix detail of design みたいなので済ませてる)
- (書き忘れた)デザイナーがプログラミング覚えるのって、デザイナーっぽいやり方をどうしてもしちゃうよね。抽象的な思考がやはり苦手だ、って話が面白かった。ホントそう。
みなさま、今回もありがとうございました。
Rails アプリ作るのが楽しくてしょうがないのだが、仕事の合間に気分転換、気分転換…と自分に言い訳しながらやってついつい夢中になってしまい本業に支障をきたすため、しばらく封印してる。。
フラットデザインのコツ的なアレ
P4Dで教えていただいたエンジニアさんに聞かれたので、なんか整理しきれてなくてざっくりなんですが、取り急ぎ、なんかそれっぽくなるコツみたいなのを独断と偏見でまとめてみました。
3色〜5色くらいの色を画面の中で均等に使うのおすすめ
作りたいサービスが何で色分けできるか考えます。ちょうどよく3〜5種類くらいのステータスやカテゴリなどがあったら、それに応じて色が変わるとかするとうまくハマる。かも。
Flat UI Colorで色選び
http://flatuicolors.com/
という便利なサイトがあって、ここから3〜5色くらい選ぶとよいです。クリックするとカラーコードがコピーされます。あら便利。赤は他の色と仲良くするのが難しめ。
Sassで彩度を抑えると落ち着いた色調になって、使いこなしの難易度が低くなります
上のサイトもそうなんですが、Flat UIによく使われている色は、鮮やかなが多くて、うまく使えるとかわいいんですが、使い方を間違えるとギラギラしてしまう可能性もあるので、彩度(鮮やかさ)を少し落としておくのが安牌でおすすめ。
こんなかんじで、上で選んだ3色をSassで彩度を10%落としてます。これで割とどのようなレイアウトでも調和がとりやすいトーンになったりします。
$color-1: desaturate(#25b89a, 10%)
$color-2: desaturate(#efc319, 10%)
$color-3: desaturate(#e57d24, 10%)
メインのテキストの色は真っ黒よりも、グレー or 濃紺が合います
グレー
#666 〜 #888 くらいの濃さ
#95A5A6, #7F8C8D (http://designmodo.github.io/Flat-UI/ 参考)
濃紺
#34495E, #2C3E50 (http://designmodo.github.io/Flat-UI/ 参考)
- 上で選んだ3〜5色 + テキスト色(グレー or 濃紺)+ あと、ベースになる色(薄いグレーかベージュ等がおすすめ)+ 白 で構成。それ以外の色を使わない。
- 色の上に白抜きで文字を載せる
- 白の上に色で文字を載せる
- rgba(0,0,0,0.1) -> 黒の透明度 0.1 / rgba(255,255,255,0.3) -> 白の透明度 0.3 等を色面の上に乗せて活用する
テキストエリアやボタンまわりにrgba(0,0,0,0.1)を使ってます
フォントづかい
Latoおすすめ
http://www.google.com/fonts/specimen/Lato
- 色んなウェイト(太さ)があって使いやすい
- http://designmodo.github.io/Flat-UI/ ここでも使ってる
数字だけ違うフォントで、2〜3倍くらいの大きさで使う
- 幾何学的に単純なスタイルの数字を持ったフォントがおすすめ
- おすすめ DIN medium > http://fontzone.net/font-details/din-medium
- 文字の大きさにメリハリをもたせるとそれっぽくなります。ポイントになる部分は大胆に大きく、それ以外の部分は小さく。
アイコンはFont Awesome で
これも数字くらいのサイズで文字の2倍くらいのサイズで使うとよい。
http://fortawesome.github.io/Font-Awesome/icons/
その他ポイント
- マージンは大きめにとる。ボタンであれば、文字の高さと同等のマージンを上下に取る。
- ボタンが認識されづらい。Submitボタンなど、押して欲しいボタンの周りにはマージンを大きめにとって、周りに何も置かないなどして目立たせる工夫必要。
- 画面の半分以上が色ベタ面になるようにする(もしくは写真を敷いてもよいです)。画面の半分以上が白だとさびしくなりがち。
- タイトル的な大きく使う文字要素は、フォントサイズを大きくして、フォントのウェイトをUltraLightなどの極細にするとそれっぽい。(やっぱり周りにマージンが大きく必要)
- 日本語をなるべく使わないw (日本語使う場合、大きな文字はboldにせず細い文字で使う、文字の周りにはマージンを大目に取る等するとよいです。)
- 写真とかボタンとかをマルにするとかわいい
思いつくの今のところこのくらいか。。。もうちょっと具体的なTIPSや色の組み合わせのパターン等をまとめて、類型化できると面白そう
しかし、図解がないのでわかりづらいな…(しかし図解をつけるのがめんどくさい・・・・いずれもうちょっとちゃんとした形に、どこかでまとめたいです。。