そんな感じで

Androidとかやってます

詳解DroidKaigiの発表準備裏側

発表準備の詳しい話をあんまり聞かない気がするので書きます。
何かの参考になれば。

準備工数

多分100~150時間くらいだと思います。

FrameLayout、LinearLayout、RelativeLayoutの内部実装読むのに10時間くらい、
ConstraintLayoutの内部実装読むのに50時間+αくらい、
スライド+原稿作成に20時間くらい、
発表練習+修正に30時間くらいでしょうか。

多分全発表者の中でもトップクラスに時間がかかってると思います。愛です。ConstraintLayoutが想像の110倍くらい複雑だったのでしょうがないです。
他の人がどのくらいの時間かけて準備したか知りたいですね。

11月中は休日と平日の帰宅後を費やして、12月と1月は休日だけ作業しました。
独身貴族で暇なのでこのくらいの時間が確保できます。
暇とはいいつつも今会社で新規案件をやっていて、アプリエンジニアとアプリデザイナーを兼任していて、ちょうど今が山場なのでさすがにしんどかったです。

11月12月で事前調査をして、
12月半ばくらいからスライドを作り始めて、
年末年始に発表原稿を書いて、
1月は練習しつつ修正という感じでした。
1月半ばに社内向けの壁打ちをやったので、その頃にはほぼほぼ資料完成してました。

発表原稿

本邦初公開、こんな感じです

f:id:seto_hi:20180211144300p:plain

発表中は多分文章が目に入ってこなくなると思ったので、重要なところを太字で書くようにしました。
これはとても良いです。オススメです。
抑揚をつけてしゃべることを意識しているので、そのあたりにも役立ちました。

僕は実際にしゃべる言葉で発表原稿を書く派です。
「完全に理解しましたね?ふぅーん..はぁ..」とかも全部書いてます。

発表で意識したこと

とにかく、多くの情報を与えることを意識しました。

今回のセッションは理解を深めるものでなく、知らないことを知るものだったと思っています。
なので、聴衆に情報を投げまくって、少しでも新しいことを知ってもらえたらなという考えです。取捨選択はそちらでしてねと思ってました。

人間は2倍速再生くらいの映画を認識できるとどこかで聞いたことがあります。(ソースが思い出せませんが)
なので、めちゃくちゃな早口であっても認識してもらえるだろうと思い、あのプレゼンスタイルになりました。

去年の発表は50分でスライド50枚くらいでしたが、今年は30分で90枚くらいです。
発表する内容によって発表方式を変えます。

発表を失敗しないために

どうしたら発表で失敗しないか。
発表で失敗する可能性がある項目を減らせばいいんです。

発表原稿を書いていないとアドリブでしゃべることになり、発表内容がぶれる可能性があります。
発表中にパニックになれば言葉が出てこなくなる可能性があります。
これらは失敗のリスクになります。
なので発表原稿を書きました。しゃべる文章で書いていているのもそのためです。

発表時間をオーバーするリスクもあります。
恐らく多くの発表は一番最後に重要なメッセージを言うので、そこを時間制限で切られるのは痛手です。
僕は各章ごとに時間を計測して、発表が想定よりも早い/遅いというのをわかるようにしていました。
時間が余ったら言う内容、時間が足りなかったら省く内容を決めていました。
ここまでやっておけば当日アドリブで余計なことを言わない限り、よほどのトラブルがない限り時間オーバーしないと思います。
発表の再現性を高めることも大事です。

発表内容がつまらなくて失敗するということもあります。
僕は聞きに来てくれそうな人に「何を期待しているか、何が聞きたいか」ということを結構質問しました。
コアユーザーにヒアリングをするのは仕事でも同じだと思います。

資料の事前公開

資料の事前公開も失敗を減らす手段のひとつです。
聴衆の人は思ったよりもセッションの詳細を読んでくれません。
こちらが発表する内容と聴衆が期待している内容が異なると「発表がつまらなかった」と言われる可能性があります。
時間をかけて準備したプレゼンに対して、本筋でない部分で批判をされる。これは最悪です。

そのリスクを減らすために資料を事前公開しました。
考えてみれば、資料がほぼ完成しているのに当日まで公開しない意味は特にないと思います。サプライズ感くらいでしょうか。

感謝

資料の事前公開ですが、僕の見た範囲だと前日の時点で10人以上の方が行ってくれたように思います。
まさか賛同していただける方がいるとは思っておらず、とても驚きました。
白山さんやこにふぁーさんや日高さんに取り上げていただいたことも大きかったと思います。
ありがとうございました。

謝罪

ただし、資料の公開についてはやり方が良くなかったと反省しています。
「資料公開しようと思っている」ツイートに想定以上の反響があり、かなり拡散していただけました。
結果として資料が完成していない発表者の方にプレッシャーをかけてしまったように思います。
ただでさえ資料作りは大変なのに、余計なプレッシャーを与えてしまったことには大変申し訳なく思っています。
ユーザーの気持ちを考える仕事をしているにも関わらず、ツイートを読んだ人の気持ちを考えられなかったことは恥です。

もう少し、何かうまい方法を考えたいと思います。

準備姿勢

準備時間が3ヶ月あり長丁場なので「気持ちが折れないように」という点を意識しました。
去年の準備は断酒をしたり飯食わなかったりと滅茶苦茶ストイックにやったんですが、体調崩したり気持ちが折れかけたりと後半に息切れ感がありました。
そもそも断酒と発表成果に関連性はあるんだっけ?無駄じゃない?と思ってやめました。

僕は訓練された人間なので、酒を飲みながら資料作ったりConstraintLayoutのコード読んだりしてました。できます。
発表原稿はだいたい年末年始に酒飲みながら書いたものです。Powered by 日本酒です。
おかげで去年よりも楽しく準備ができたと思います。

何が本当に必要なことがを考えましょう。仕事と一緒ですね。

来年に向けた改善点

・効率的に調査・資料作成できるようになりたい
・スライドの見た目をもう少し改善したい
 ・でもあまり本質でない気がする
・体重を維持する手段を考える
・健康を維持する手段を考える
・睡眠時間を維持する手段を考える

DroidKaigi2018で発表しました

改めまして初めましてハロー、@seto_hi です。

DroidKaigi2018で「詳解ViewGroupのレイアウト内部実装」を発表しました。
恐らく3本くらいDroidKaigiに関するブログ*1を書きますが、これは発表についての記事です。

 

f:id:seto_hi:20180210100837j:plain

発表者と会場です。全く緊張してなくて、発表前に余裕で自撮りしてました。

 

資料

speakerdeck.com

資料の付録

1. 詳解 RelativeLayoutの内部実装 // Speaker Deck

2. ConstraintLayoutの機能の実現 // Speaker Deck

3. ノハナ社のレイアウト戦略 // Speaker Deck

1と2は発表の延長戦ですが、3はViewGroupの使い分けなどを書きました。
ものすごく有用*2だと思っているので是非読んでください。
こんな図とか入ってます。

f:id:seto_hi:20180210114856p:plain

 

セッションについて

朝一のセッションであり、かつ実用性があまりないセッションにもかかわらず、多くの人に来ていただいて驚きました。
日本にこれだけの数のViewGroupが好きなエンジニアがいるならば、日本の将来は明るいと思います。
また半分くらいの方が事前に資料を読んでくださったようで、事前公開した意味はとてもあったのかなと思っています。想像以上です。

今年は声が枯れることもなく、練習通りのことができたのではないかと思います。 
発表時間は手元の計測だと29分56秒でした。完璧ですね。

「メモを取らない方が良い」ということを言ったせいだと思うのですが、ツイートも少なくてセッションの感想が全然見えていません。
セッションに来てくれた知り合いに感想を聞いて回ったりするくらい見えていません。
よかった!という話は当然嬉しいですが、発表で不満だった点、理解が難しかった点が聞きたいです。それを聞けないと発表者として成長できません。
Twitterでも勉強会で会った際にでも是非教えてください。

オフィスアワーは質問が少なく、暇でした。
カンファレンスの良いところは、発表者が同じ会場にいて、直接会話することができることだと思っています。
質問をしない・感想を言わないのならば、アーカイブされた動画を家で見てるのと変わらないと思います。

発表内容について

発表の40分前にConstraintLayout1.1.0-beta5が公開される事件はありましたが、ちゃんと内部実装を読んでから発表しました。

「早口だけどわかる、完全に理解した(わかってない)*3」といういったような感想が何件かあって嬉しかったです。狙い通りです。*4
Cassowaryについては何をしているかをなんとなく理解してもらえればよく、それ以上のことは狙っていませんでした。なので完全に理解できなかったとしてもそれが正しいと思います。Cassowaryすごい、ConstraintLayoutすごい、それだけ分かってくれればいいんです。

みんな大好きレイアウト

Romain GuyとChet Haaseのセッションや、ConstraintLayoutのセッションでもレイアウトまわりの話が上がっていました。
ちょうど自分のセッションで話した部分が多く出てきて、謎の感動がありました。

資料にちょこっと書いたTraversalRunnableとかマニアックな話がRomainとChetのセッションでも出てきてマジか!マジなのか!!!と思いました。
ConstraintLayoutのセッションでもRelativeLayoutは2回measureするよねみたいな話があって、これ付録に書いた話だ!と感動しました。

自分のセッションが先だったので良かったですが、逆だったら爆死していたと思うので本当によかったです。

ConstraintLayoutの中の人と話した

ConstraintLayoutのセッションのオフィスアワーでNicolas RoardとJohn Hofordと話しました。英語全然得意じゃないけど突撃しました。
以下の内容は間違っている可能性があります。

「今朝ConstraintLayoutについて発表したけど、直前のアップデートには驚いたよ」と言ったら「どうなるか心配だったよ〜」的なことを言われました。そうですね。

Optimizerの存在意義について聞いたのですが、僕の発表した通りの内容で合っていたと思います。
ConstraintLayoutは基本的には高速、でも計算量がレイアウトと見合わない場合がある、そういった時に使うんだということです。

ConstraintLayoutのセッションでは2.0で計算が速くなると言っていました。
これも聞いたところ、よくあるレイアウトについてはOptimizerで解決できるようにしてsuper fasterにするということを言っていたと思います。(英語を全然聞き取れなかったのでちょっと自信がないです)
なぜsuper fasterになるかは、僕のセッションを聞いた人なら完全に理解できると思います。

内部実装を読んでいるときにもOptimizerはもう少し頑張れると思うんだけどな〜ここを強くするのかな〜という感想だったので、読みが当たって嬉しいです。

中の人と話せるなんてめっっっっっっちゃ貴重な機会だったのでとても嬉しかったです。
ConstraintLayou最高!って言いそびれたのが反省です。

最後に

いろいろな方への感謝を言いたいです。

まずは素晴らしい場を提供してくださった運営の方々、本当にありがとうございました。

Cassowaryの理解に大変役立つ発表をしてくださった @inamiyさん、本当に感謝しています。どこかで直接お礼を言いたいです。

かなり早い時期からセッション楽しみにしているよーと言ってくれたむーむーさんとふじたくさん、ありがとうございました。2人に楽しんでもらえることを目標にして準備頑張っていました。

セッション聞きに来てくださった皆様、ありがとうございました。フィードバック待ってます。

 

以上、まだどこかでお会いしましょう。
DroidKaigiが終わったので3月の勉強会の準備せねば...

*1:発表、準備、プレゼンとか

*2:もっともっと有用にしたい、でも何書いていいのかわからない

*3:某画像をスライド内で使いたかったけど著作権的に諦めた

*4:このあたりも別途記事にします

DroidKaigi2018「詳解 ViewGroupのレイアウト内部実装」の資料を事前共有します

Hello! @seto_hiです。

2/8の DroidKaigi 2018 の2日目の10:30〜「詳解 ViewGroupのレイアウト内部実装」という発表をします。
朝一ですが濃いセッションをやります。覚悟してください。

このツイートの有言実行です。
この件の詳細については、DroidKaigiの振り返り記事に書こうと思います。

なお、資料についてはすべてRC(Release Candidate)版です。
小さな修正は確実に入ります。また、間違いや間違っていそうな点がありましたら遠慮無くマサカリをお願いします。誤った内容を発表したくないので。

セッション資料

ご査収ください。 

speakerdeck.com

このスライドを見て、「思っていたのと違う」「全く理解できない」「完全に理解した(していた)」という方は、申し訳ありませんが今回の発表のターゲットではありません。別のセッションに行かれた方が良いかと思います。
「3〜7割くらい理解できた、説明を聞いてもっと理解を深めたい」という方は是非セッションを聞きにいらしてください。パーティーでもセッション前でも後でも質問大歓迎です。
発表を聞くだけなら後日動画を見ることもできますが、発表者と話すことはDroidKaigiの2日間しかできません。話しましょう。
完全に理解した方は、別の機会で深く話しましょう!

ConstraintLayoutについてはかなり浅い内容になってしまっています。
もっと内部の深い話をしようと思っていたのですが、ひとりでDroidKaigiが開催できるくらいの内容になってしまいそうなので今回は省きました。
需要はなさそう、どこかで発表したいという気持ちはあります。

付録

なんとこのセッションには3つの資料があります。
付録の内容について、セッションでは一切触れません。
最初に勢いだけでスライドを作っていたのですが、60分くらいの内容になってしまいました。かといってお蔵入りにするのも惜しいので公開します。

付録1 詳解 RelativeLayoutの内部実装

発表ではFrameLayout、LinearLayoutしか触れませんが、RelativeLayoutについても調べました。
循環参照の検知の実装はとても面白いので、資料を読んだ後に是非コードも読んでみてください。

 

speakerdeck.com

付録2 詳解 ConstraintLayoutの機能の実現

本来はセッションに含む予定だったのですが、時間の関係で省きました。
申し訳ありません。詫びスライドです。

 

speakerdeck.com

付録3 ノハナ社のレイアウト戦略

これは本当のおまけです。
セッションの内容が実用的でないので、少しくらい実用的なものを提供しよう気持ちです。
レイアウトどうしてますか、どうしたらいいですかとよく聞かれるので、良い機会だと思って明文化してみました。
もっと内容を拡充したいので、質問や要望などをお待ちしております。

 

speakerdeck.com

最後に

資料を公開しましたが、自分の発表の価値は資料だけではないと思っています。
文字や図だけでは伝わらない内容を理解させるために日々発表練習を重ねています。
当日はご期待ください。

DroidKaigiでお会いしましょう!

エンジニアがアプリデザインに関わっていくために必要なこと

あけましておめでとうございます。
最近業務で新規アプリを作ってるのですが、アプリデザイナーも兼任してます。
やっていく中で必要だなぁと思うことがあったので書き連ねます。

今のチームではAndroidエンジニア兼アプリデザイナーの自分と、プロダクト全体のデザインを見ているデザイナーがいます。
UIに関しては自分が担当して、配色やエモい画像とかはデザイナーが担当する流れになっています。

技術

「簡単に実装できること」を知っておくべきだと思います。
どうでもいいところなのに実装工数がかかる、みたいなデザインを作ってしまったらエンジニアがデザインをやる意味がありません。
「簡単に実装できること」を知るには網羅的に勉強をする必要があってまぁ大変です。
経験を積むしかないんでしょうか。

「どこまでなら実現できるか」を知ることも必要だと思います。
こだわる部分はこだわったUIにすべきで、それがどこまでなら実現できるかを知っておくべきです。
自分がViewGroup芸とかCanvas芸をやっているのはこのためです。

あとアニメーション系を簡単に実装できるようになっておくべきです。
Material Designだと意味を伝えるためにアニメーションは超重要です。が、それ以外にも微妙なデザインをよく見せるためにも使えます。
AndroidだとAnimation(Animator)やTransitionあたりですかね。
Transitionは便利なのにみんな使ってない感があるので勿体ないと思います。

知識

Material DesignとかHuman Interface Guidelinesは理解しましょう。
読むだけではダメです。理解するんです。

他人に説明できることを目標にすると良いと思ってます。
昔デザイナー相手にMaterial Design勉強会をやったのはいいプレシャーでした。

ツール

画面のレイアウト案を表現できるツールを使えるようになっておくべきだと思いました。今だとSketchあたりでしょうか。
業務でやるなら画面遷移図とか作る必要があると思いますし、自分以外のエンジニアへのデザイン指示をするにも必要です。

あと簡単なアイコンくらいは作れるようになっておくと良いと思います。
ちょっと直したい、みたいなときに自分で手を動かせるのは便利です。
SVGを生でいじるのはよくやるけどオススメしないです

センス

美的センスを付けましょう。
センスという言葉は色々ニュアンスがありますが、ここでは「何が優れたデザイン・美しいデザインであるかを理解し、デザインを自分で再現できる」という意味で使います。
デザインに関わるものに触れる機会を増やすことで美しいデザインが何かを理解できるのではないかと思っています。自分は他社アプリを触ったり美術館に行ったり本を読んだりしています。
デザインを再現できるようになるためには手を動かすしかないと思います。何もしなければ何も上達しないので悩んで手を動かして試行錯誤して経験を積むしかないです。

余談ですが、自分は深澤直人さんのシュッとしたデザインが好きでそれに近いデザインを作りがちなのですが、家族向けサービスにあんまり合わなくて悩んでいます。

もの

デザイナー感を出すためにiMacを買うといいと思います。冗談です。
iMacは画面が綺麗なので持っておくと良い気はします。画面が大きくてマルチタスクに便利ですね。

相談相手になってくれるデザイナーがいると心強いです。
デザイナーは経験が豊富なので、強いなというのを再認識しました。
師匠になってくれるデザイナーがいると最高だと思います。
師匠欲しいです。

 

以上!

3月にアプリデザイン好きなエンジニア向けの勉強会やりますよ!ご期待ください!

2017年総括

仕事納めたので総括します。皆様には大変お世話になり、圧倒的成長をできた良い1年でした。

Android

DroidKaigi

3月にDroidKaigiで発表して、すさまじいフィードバックを貰ってエモくて死にそうになりました。
会場の中で10人くらいの人に深く刺さればそれ以外は評価されなくていいと思ってたのですが、結構な人に刺さったようで何よりです。
採用系でお話させていただいた方もかなりの割合でスライド or 動画見ましたと言ってくださるので怖いくらいです。
おかげさまで界隈の知り合いも増え、色々な技術話を聞けるのでとてもハッピーです。
本当にDroidKaigiには感謝しかありません。

そしてDroidKaigi2018にも採択されました。
ViewGroupの内部実装なんて誰も興味ないだろと思ったらそんなこともなかったみたいです。変態がいっぱいいて嬉しいですね。
年末年始はスライド作成に費やしますので、DroidKaigi 2018の発表もご期待ください。

実装

Kotlinを本格的にやったり、Rxを本格的に使いはじめたり、設計をMVVMにしてみたりClean Architectureっぽくしてみたりと色々トライしました。
設計は勉強してもよくわからなかったのでエイヤーとやってみたら利点がとても理解できました。一段階レベルアップした気がします。沼ですね。

iOS

気が向いたので一時期業務でiOSアプリ書いてました。

3年くらい前にiOS開発やったときは全然楽しくなかったのですが、多分Objective-CXcodeのせいだったみたいです。
思ったよりスイスイとSwiftが書けたので楽しく開発できました。でもやっぱりXcodeは嫌いです。

2018はもうちょっと深くやってみようかなという気持ちがあります。AppCodeで。

デザイン系

色々なところで俺はUIデザインできるぞ!って言ってたり自己紹介でUIデザイナー名乗ったりしていました。すると現在開発中のアプリでは本当にUIデザインをフルで担当することになりました。

0からアプリのUI考えるのは想像の64倍くらい大変で、コーティングよりも悩んでいます。本当に悩みます。

あと、デザイン系の勉強会に行くと全然違う観点の方がいらっしゃって面白いなーと思いました。
デザイン系の学部出身じゃない人にどうやってデザイン勉強会したかをよく聞いています。

来年はSketchを買って、もっと本格的にやっていきたいです。VectorDrawableを直書きするのは疲れました。

 やりましょう。

勉強系

今年はあんまり本を読めませんでした。
趣味で心理学の本読んでるのですが、マズロー心理学の本と暗黙知の本が面白かったです。
年末年始でデザイン系の本何冊か読みます。

英語

5月くらいに英語熱が爆発して、通勤中に英単語帳を読んでいたのですが1ヶ月で飽きました。単語帳は効率悪いですね。
その後は何もしてなかったのですが、10月から社内TOEIC講座で毎日15分英語アプリで勉強しろという課題を課され、毎日地道にやっています(10分くらいしかやらない日が多いですが)
高校大学時代に英単語の勉強を一切しなかったせいで単語力が全くないので、mikanというアプリでコツコツとやっています。隙間時間でできるのが良いです。
来年のGoogle I/O行くために頑張ります。

仕事系

色々評価されて年収がビットコインくらい上がりました。去年から地道に勉強していたら実力がついたみたいです。来年は5000兆円まで昇給したいです。
気付いたら会社でも古株になっていて、ほどほどに責任がついてくるポジションになりました。効率良く結果を出して行きたいです。

施策考えて実装して効果測定して改善するサイクルをよく回せました。
ユーザーがどう動くかはリリースするまでわからないので楽しいですね。

体調

DroidKaigi前に胃腸炎になった以外はほぼ体調崩しませんでした。
腸炎とDroidKaigi疲れで体重が5キロくらい落ちてしまい、夏くらいまで体力が戻らずにフラフラでした。このダイエット方法はオススメできません。
6月に良い敷き布団を買ったのですが、とても良いのでみなさんも是非寝具にお金をかけるべきだと思います。でも寝過ぎてしまうのが欠点です。

その他

今年は163日休肝できました。去年よりも人と飲むことが多くて楽しかったです。
でも深酒することが多かったので星一つです。

 

一年間お疲れ様でした。

2017年飲んだ日本酒まとめ

@seto_hi です。Androidと日本酒とYUKIが大好きです。

最近エンジニア方面の方と日本酒の話をすることが多くなってきたので、今年の日本酒のことを振り返ってアピールしておきたいと思います。

今年の前半は日本酒飲み放題のお店によく行っていたので、130~180種類くらいは飲んだと思います(しかし半分くらいがお猪口1杯程度しか飲んでないので印象も薄い)。趣味の旅行ついでに酒造も10軒くらい行きました。
どの日本酒もおいしかったのですが、特に印象に残ったものを書きます。印象に残るくらいなのでくせ者が多いです。超有名どころはあんまり書かないです。

 

おいしかった日本酒

高砂酒造 一夜雫 大吟醸

去年末に旭川に行った際に買いました。蔵の最高級のお酒なのでそりゃおいしいよねという感じです。お正月にいただいたのですが、メロンのような甘い香りが最高でした。
アイスドームの中で絞るという北海道ならではのお酒なのですが、近年の温暖化の影響によって昨年度分で生産終了らしいです。残念。

松みどり 純米吟醸 生酒 720ml

地元のお酒です。酉年限定パッケージがかわいかったです。
生感が強めで味もあり、地元にもこんなおいしいお酒があるのかと思いました。

新政 陽乃鳥 オーク樽熟成

今年一番はこれです。普通の陽乃鳥も好きですが、全然違います。新政大好きなのでかなりの種類を飲んでますが、全然違います。
貴醸酒をオーク樽熟成させたものなので日本酒の味とは結構離れているのですが、香りと甘みのバランスが最高でした。

加茂錦 荷札酒 月白 純米大吟醸 無濾過・仲汲み

日本酒居酒屋でお店の人に進められて飲んだのですが、最高でした。
ガス感と生感と香りの良さと味とすべて文句なしです。この1杯で加茂錦に完全にハマりました。

満寿泉 純米大吟醸 ワイン樽熟成

シェリー樽で熟成した日本酒です。スッと入ってきて完全に死ねます。味も香りも最高で、とても良いお値段がします。でも気付いたら買ってました。お酒は判断力を低下させますね。
富山駅のお土産街で20ccくらい?で200円で飲めます。

気に入った日本酒

クセが強いけど気に入った子達です

悦凱陣 純米山廃 無濾過生原酒 赤盤雄町

香川のお酒で、現地に旅行に行ったときに蔵で直接買いました。行ったときはちょうど火入れしてました。
味が非常に濃く、変態と言われている蔵です。大量生産する感じではなく、我が道を行く味がします。それだけでなく、生酒なのに開栓してから常温で保存してもダメにならずに変化するド変態です。
1ヶ月常温で熟成させたところ、味と甘みが濃くなって思わずうなりました。うっかり半年ほど熟成させたところ、アルコール感が薄くなりやや飲みやすくなっていました。
来年も熟成させたいです。

瀬戸の花嫁 純米大吟醸

これも四国に行ったときに蔵で買いました。自分が瀬戸なので半分ネタで買ったのですが、おいしかったです。あとちゃんとウケました。
オオセトという日本酒好適米で作っているのでこの名前らしいです。
グレープを思わせる香りと書いてありましたが、僕はグレープフルーツの香りを奥の方に感じました。程よい苦みが良いです。

甲子 林檎 KINOENE APLLE

千葉の酒造巡りをしたときに買いました。後輩と2人で試飲したのですが、2人とも完全に惚れて即買いました。リンゴ系の酵母で甘さと酸味のバランスが良く、ワイングラスでおしゃれに飲みたいお味でした。
DeployGateさんのデプロイ肉の時に差し入れしたのですが、おいしすぎて自分でも結構飲んでしまいました。

華鳩 しおり 貴醸酒8年貯蔵

貴嬢酒の古酒です。古酒なので当然独特の香りはありつつも、あまりしつこさもなく甘くて飲みやすかったです。

達磨正宗 熟成三年

行きつけの店の店長がこっそり飲ませてくれました。これは3年熟成とは思えないくらいの濃さがありました。
みりんに近い系の古酒です。クセになります。

 

レア感

上川大雪酒造 試験醸造酒 1号

旭川で友人に地元の人しか行かないようなお店に連れて行ってもらい飲みました。
今年飲まないと二度と飲めません。ちなみに家にも1本眠っています。
ふるさと納税もこちらの蔵のお酒目当てで上川町にしました。

 

名前が好き

・恋をするたびに
 ・1~5話までサブタイトルもあるけどなぜか泥沼エンドに..

・I love sushi
 ・ラベルもかわいい

・パンダの旅
 ・ラベルもかわいい

・飲めばわかる
 ・わかりました

 

来年に向けて

クラウドファンディングした農口さんの日本酒が届きます

ふるさと納税した上川大雪酒造の日本酒が届きます

・来年も旅行がてら蔵巡りをする

という予定が既にあります。

来年も日本酒まみれ確定ですね!飲んでいきましょう!

FloatingActionButtonはなぜ画面右下か

mixiグループ Advent Calendar 2017 4日目の記事です。

Qiitaに書こうかと思っていましたが、完全にポエムになったので自分のブログに書きます。長いです。

 

時間がない人向けに結論だけ

・人間の目線は画面左上から右下に動く

・なので、左上→右下に目線が流れる動線にした方が自然

・FABには次の画面に繋がったりするようなアクションしか置いてはいけない

・FABを画面右下に配置すれば画面全部を見た後に次の画面に行けて自然な動線になる

 

自己紹介

@seto_hi です。株式会社ノハナAndroidエンジニアをやりつつアプリのUIデザインを考えたりしています。

Material Designが好きで、DroidKaigi2017でMaterial Designに関する発表をしたり、知り合いからはMaterial Design警察と呼ばれたりしています。

 前提

僕は「Material Designはプラットホームである」という考え方に賛同しています。Material Designのガイドラインに書いてあることがすべてではなく、背景を理解してガイドラインに書いていないことを行ってもいい(もっと言えばガイドラインを破ってもいい)という考えです。

 

本題

FloatingActionButton(以下FAB)がなぜ画面右下にあるかについて本気出して考えます。厳密に言うとLTR言語ではFABが右下にあり、RTL言語ではFABが左下にある理由を考えます。

なお、今回はAnchorありFABについては言及しません。

右利きが操作しやすいから右下?

世界に右利きの人が多く、画面の右下にボタンを置けば一番操作しやすいからという考え方はあると思います。

しかし、RTL言語の方向けの画面ではFABは左下に配置されます。RTL言語を使う国でも右利きの人が多いらしく、FABを左下に配置することは操作性の低下に繋がります。

RTL向けのUIでは左右反転するものとしないものがあります。操作性だけを考えるならFABの位置も反転しなくても良かったのではないでしょうか?

これを考えると操作性のため「だけ」に右下に配置しているのではないような気がします。

(ユーザーの大半を占めるLTR言語の人に操作しやすいという観点も当然入っていると思います)

Androidの世界と右と左

Androidの世界では画面の左右の配置に意味があります。

右は未来・肯定などを表し、左は過去・否定などを表します(RTLの場合は逆)。

例を挙げるとBackボタンやHomeAsUpは画面左にあり、ダイアログのボタンは右側に肯定アクション、左側に否定アクションを置くことになっています。 

なぜ右が未来・肯定、左が過去・否定

これは人間の目線の動きに由来していると考えています。

人間の目は文章を読むときにZ字型に目線が動くと言われています。アイコン付きリストの場合には逆N字型と言われています。

画面の最右に次の画面への動線を置くと、目線が左から右に進んだ先で動線にたどり着くので自然な体験になります。

肯定的な内容は次の画面へ進む動線になることが多く、否定的な内容は前の画面に戻る動線になることが多いです。

このような理由から、「右が未来・肯定、左が過去・否定」という世界になったのだと思います。

FABのガイドライン

 FABのガイドラインには、ボタンに置くべき操作についての記載があります。

雑にまとめると、

・ポジティブなアクション(新規作成、お気に入り、共有、Navigate、Exploreなど)は置いて良い

・マイナーだったり破壊的なアクション(削除、エラー、具体的でないアクション、操作系)は避けるべき

となっています。

これとAndroidの左右の話を合わせると、FABは画面右に配置することが正しいという気持ちになりました。

 

結論

・人間の目線は画面左上から右下に動く

・なので、左上→右下に目線が流れるUIにした方が自然

・FABには次の画面に繋がったりするようなアクションしか置いてはいけない

・FABを画面右下に配置すれば画面全部を見た後に次の画面に行けて自然な動線になる

 

記事は以上です。

 

蛇足

色々とUIを考えていくと、UIに関する疑問が湧いてきました。

・NavigationDrawerの呼び出しボタンは画面左上だが否定的な内容ではない

 ・左上にバーガーメニューを置くのは慣習になっていますが、実はMaterial Design的ではないのでは?

・Toolbarの右部分に表示されるActionMenuに操作アクションを入れることは、FABのアクションの制約と同じ理論で考えると良くないことでは

・メールなどの一時保存ボタンはメールの作成画面を閉じることになるので、画面左側に配置すべき?

このあたりの議論をしたい方、答えを知っている方、是非お声がけいただきたいです。

 

以上!いいポエムが書けました!