Slide 1

Slide 1 text

エンジニアが武器にする Material Design DroidKaigi 2017 株式会社ノハナ 瀬戸優之 @seto_hi

Slide 2

Slide 2 text

自己紹介 ● 瀬戸優之 せとひろゆき @seto_hi ● Android開発歴 6年半くらい ● コンシューマー向けAndroidアプリ開発一筋 5年 ● 株式会社ノハナ ○ 唯一のAndroidエンジニア ○ 絶賛採用中 ● 好きなAPIはCanvas#saveとViewGroup#layout

Slide 3

Slide 3 text

なぜエンジニアがデザイン? ● 大学の研究分野がHCI ○ コンピュータを使いやすくするUI研究 ● 前職ではUIデザインも担当 ○ デザイナーはアイコン作るだけ ● 現職では新卒デザイナーとチーム ○ Androidアプリデザイナーとして教育

Slide 4

Slide 4 text

僕とMaterial Design 2014/06  I/Oで発表されて知る 2015/11  アプリの主担当になる 2015/12   「今のデザイン全部捨てようぜ!」 2015年末   ガイドラインを読み始める  年末年始休暇でひたすら読み込む 2016/01  社内Material Design勉強会 2016/01/26 新規登録画面をMaterial Design化してリリース  1年かけて全画面フルリニューアル 2017/1/17  全画面のMaterial Design化完了

Slide 5

Slide 5 text

ノハナノハナシ [検索]

Slide 6

Slide 6 text

デザインエンジニア推進派 ● 「デザインはデザイナーに任せるには重要すぎる」 ○ アプリデザイン ≠ Webデザイン、グラフィックデザイン ○ アプリデザイン=UIデザイン+ユーザー体験のデザイン ■ 必要な知識が多い ● アプリエンジニアもユーザー体験に責任を持つべき ○ 理解していないデザインを実装してない?

Slide 7

Slide 7 text

今日言いたいこと ● エンジニアがアプリデザインに関わると捗る ○ 工数削減、アプリの質の向上、体験の改善 ● アプリデザインの勉強としてMateiral Designは良い ○ 知識と実装が繋がると武器になる ● エンジニアから社内にMateiral Designを広めよう ○ 社内勉強会をやろう ● ガイドライン通りでは他社に勝てない ○ 深読みしてMateiral Design力をつけよう

Slide 8

Slide 8 text

目次 ● エンジニアとアプリデザイン ● Mateiral Designを武器にする ● ノハナ社でのMaterial Design導入方法紹介 ● 深読みガイドライン

Slide 9

Slide 9 text

エンジニア と アプリデザイン

Slide 10

Slide 10 text

エンジニアがアプリデザイン関わる利点 ● デザイナー負荷削減 ○ 巻き戻りの幅が小さくなる ○ デザイナーがAndroidにとっつきやすくなる ● 開発の時短 ○ デザイン待ち時間削減 ● アプリの質の向上 ○ 巻き戻りしやすい ○ 多視点で判断できる

Slide 11

Slide 11 text

エンジニアがアプリデザイン関わる欠点 ● エンジニアに負荷がかかる ○ コーディングにフルコミットできない ● デザイナーはデザインチームとエンジニアの板挟み(かも) ● 論理的な反論に慣れていないデザイナーはつらい(かも) ● 理論的に正しいが微妙なUIができる可能性 ○ 時には直感を信じることも必要 ● 一部デザイナーから反発がある

Slide 12

Slide 12 text

アプリデザインとどう関わるか ● やりすぎない ○ 協力してお互いをカバーする ● デザイン領域には口を出さない ● 最終決定権の所在を明らかにする ○ デザイナーが持つと幸せ ● アプリデザイナーを育てる ○ OSの世界観とアプリデザインを教える

Slide 13

Slide 13 text

Material Design を 武器にする

Slide 14

Slide 14 text

Material Designで学ぶアプリデザイン ● 現実世界がベースなので理解しやすい ● リファレンスを読むことに抵抗がない ● 学習と実装が同一人物 ○ イメージ通り作れる ● エンジニアでもそこそこのUIが作れる ○ UIを理論で組み立てられる ○ そこそこ以上はデザイナーが必要

Slide 15

Slide 15 text

どう学ぶべきか とにかくガイドラインを読む 1. Mateiral Design ○ Introduction、Environment、Material Properties、 Elevation & shadows 2. Components、 Patterns 3. Layout、Style、Motion 4. Growth & communications、Usability

Slide 16

Slide 16 text

どう武器にしていくか ● 工数削減 ○ デザイナーと協力して工数を減らす ● 知識と実装を繋げる ● エンジニアだからこそできる改善をする

Slide 17

Slide 17 text

知識と実装を繋げる 繋げるために必要な勉強 ● 用意されているViewコンポーネントを知る ● Themeを理解する ● Viewの実装を学ぶ ○ View#measure、ViewGroup#layout、Canvas ● アニメーションの実装を学ぶ ○ Animator、Transition、Drawable

Slide 18

Slide 18 text

エンジニアだからこそできる改善 ● UIだけでない「体験」の改善 ○ ≒高速化、爆速化 ● RAILパフォーマンスモデル ○ ノハナ社ではアプリ向けに修正 ■ 遷移開始はユーザーアクションから100ms以下 ■ アニメーションは1フレーム16ms以下 ■ ユーザーを待たせる処理は1000ms以下 ■ 1000ms以上のタスクは完全バックグラウンド ユーザー操作を妨げない

Slide 19

Slide 19 text

エンジニアだからこそできる改善 例:プレビュー画面 ● Activity起動から表示までの中央値が1800ms ● LogとSystraceで徹底分析 ● 分割・遅延読み込み、レイアウト最適化 ● 結果:160msまで改善

Slide 20

Slide 20 text

ノハナ社での Material Design 導入方法紹介

Slide 21

Slide 21 text

ノハナ社Androidチームの仕事 ● 期初に数値目標を渡される ● 現場で施策を考える ● 目標に向かってPDCAを回す

Slide 22

Slide 22 text

ノハナ社のAndroidチーム ● アプリエンジニア1人、アプリデザイナー1人、QA1人 ○ 基本的にはエンジニア+デザイナーで仕様検討 ○ QAがコアユーザー層と被るので意見をもらう ● サーバーエンジニア、マーケ、CS(各1人) ○ みんなスペシャリスト

Slide 23

Slide 23 text

課題の洗い出し 施策決定 プロト レビュー QA デザイン確認 リリース 振り返り 実装 指示書作成 エンジニア デザイナー QA

Slide 24

Slide 24 text

エンジニアがデザイン関わる利点 ● デザイナー負荷削減 ○ 巻き戻りの幅が小さくなる ○ デザイナーがAndroidにとっつきやすくなる ● 開発の時短 ○ デザイン待ち時間削減 ● アプリの質の向上 ○ 巻き戻りしやすい ○ 多視点で判断できる

Slide 25

Slide 25 text

社内へのMaterial Design導入 導入 ~デザイナーへの周知~ ● 社内Mateiral Design勉強会 ○ 概念、世界、Viewコンポーネント ● 社内アニメーション勉強会 ○ 何ができる、どのくらい工数がかかる ■ ドキュメントにして共有 ○ 「何ができる」を共通言語化

Slide 26

Slide 26 text

社内へのMaterial Design導入 発展 ~デザイナーの教育~ ● 読んで欲しいガイドラインを明示 ○ 次版で必要な部分を先読み ● 根拠のある話し合い ○ なぜそのデザインになったか聞く ○ なぜそう思うのか根拠を言う

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

アップロード画面のリストの区切り線が結構目に付いています。 多分2dpになっている(本来は1dp)のもあると思いますが、TextFieldの 線とリストの区切り線で二重になっていることが主原因かと思います。 二重になっている意図がないならばどちらかをとってしまいたいと思いま した。 ● Material Designではあまりリストの区切り線を描画しないので、 取ってしまってもよいかと思います。 ● 逆にTextFieldの線を取るのもアリで、 https://material.google.com/components/text-fields.html#text-fiel ds-character-counter のFull-width text field with character counterのようなレイアウトで も良いと思います。

Slide 29

Slide 29 text

アップロード画面のリストの区切り線が結構目に付いています。 多分2dpになっている(本来は1dp)のもあると思いますが、TextFieldの 線とリストの区切り線で二重になっていることが主原因かと思います。 二重になっている意図がないならばどちらかをとってしまいたいと思いま した。 ● Material Designではあまりリストの区切り線を描画しないので、 取ってしまってもよいかと思います。 ● 逆にTextFieldの線を取るのもアリで、 https://material.google.com/components/text-fields.html#text-fiel ds-character-counter のFull-width text field with character counterのようなレイアウトで も良いと思います。

Slide 30

Slide 30 text

before after

Slide 31

Slide 31 text

深読み ガイドライン

Slide 32

Slide 32 text

ガイドラインを深読みする ● Material Design力を鍛える ● 「なぜその仕様なのか」を考える ○ 答えはない ● ガイドラインに書いていない仕様を想像できる ● ガイドライン外のことをやりやすくなる

Slide 33

Slide 33 text

例1:Bottom navigation > On Android, the Back button does not navigate between bottom navigation bar views. BackボタンでBottom navigationのview(content)を操作するな

Slide 34

Slide 34 text

Bottom Navigation Back可 ● Activityを閉じるとき ● Dialogを閉じるとき ● Navigation Drawerを閉じるとき ● Bottom Sheetを閉じるとき Back不可 ● Bottom Navigationのview(content)の戻り

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

BottomNavigation 結論 ● Backボタンは画面の一番上のelevationの View全体を隠す(消す)際に使うべき ● BottomNavigationのcontentは 画面の一番上のelevationのViewではない ○ Backできるべきではない

Slide 37

Slide 37 text

例2:Progress Dialog ● ガイドラインに載っていない ● support libraryにもない ● なぜ?

Slide 38

Slide 38 text

Dialogs ● > Use dialogs sparingly because they are interruptive. ● ユーザーの操作を強制的に止めるもの ○ 特にcancel不可なProgress Dialog ● elevationは24dp ○ Pickerと並んで最大

Slide 39

Slide 39 text

Progress Dialog 結論 ● 待たせる際もユーザーの操作を止めるなという意図 ○ Googleのアプリでは完全バックグラウンドが多い ○ 待たせる場合でもユーザ操作可能なUI ● そもそも1秒以上待たせない

Slide 40

Slide 40 text

まとめ

Slide 41

Slide 41 text

まとめ ● エンジニアがアプリデザインに関わると捗る ○ 工数削減、アプリの質の向上、体験の改善 ● アプリデザインの勉強としてMateiral Designは良い ○ 知識と実装が繋がると武器になる ● エンジニアから社内にMateiral Designを広めよう ○ 社内勉強会をやろう ● ガイドライン通りでは他社に勝てない ○ 深読みしてMateiral Design力をつけよう