2015年1月30日

UIモックは「後で捨てるから見た目さえ守ればつくりはどうなっててもいいプログラム」ではない

UIモックを後輩が作っててイマイチだったので、その際のレビューで説明したことのメモ。

【※2015.01.31追記 UIモックについて】
「UIモック」というと、デザインカンプの画像に画面遷移だけをつけたものや、手書きでUI構造を書いたものを複数パターン用意するペーパープロトタイピング時に作成するものを差す方が普通と思われますが、本エントリでのUIモックは、ウォーターフォール的な開発行程の中で、「完成系のイメージを早めに顧客合意をとり、後ろでひっくり返されないこと避ける」ために作るUI・UX設計の上流行程の成果物としてのUIモックのつもりで書いております。紛らわしくてすいません。
# 紙芝居を見せて「できてるじゃん」系カンチガイの方とは相性が悪いのですが、僕はダサダサ見た目の機能プロトを作ってからデザインを刷新するよりは勝率が良いと思っています。とくにOSの仕組みと相性が悪い「見た目だけ華やかなクソデザイン案」が顧客から提示されてしまっている際に重要度が上がる認識です。


1. システムバー/ナビバー/アクションバーやドロワー/ダイアログなどOS標準にそぐわないデザイン案がベースの際には最初にひっくり返しましょう

システム・OS側UI要素や、iOS←→Android等のOS超え知識が不十分な人が書いたデザイン案は必ずこのあたりにムリがあります。最初にひっくり返しましょう。
最近は減りましたが右上に×ボタンとかちょっと前まではよく見ました。

デザイン案をもらったその日に「その絵を書いた人がOS毎のユーザーガイドラインを意識しているかどうか」を判定し、「モックではOS別のガイドラインにあわせた形のものをご用意させていただきます」あたりは先に言っておきましょう。


2. アプリ名・パッケージ・ランチャーアイコンは最初に時間を割きましょう

「(顧客名)試作」とか「通信アプリ」とか「com.(会社名ドメイン).sample」みたいなのにすると後で泣きます。ドロイド君ランチャーアイコンで開発を始めるのは自殺行為です。

今把握している限りのイメージを詰め込んで、アイコンはLauncher Icon Generatorで真剣に10分悩んで、テーマカラーも決めておくべきです。

Launcher Icon Generator
http://romannurik.github.io/AndroidAssetStudio/icons-launcher.html


3. テーマカラーとカラーチャートは最初に起こしましょう

Material Designを意識したものでなくとも、Colorだけはここから選んでおきましょう
http://www.google.com/design/spec/style/color.html

color.xmlでのカラー定義は"orange500"や"blue300"の様な物理(?)名と"color_main_bar", "color_accent_font"の様な論理(?)名を両方書いて二段参照にするのが望ましいです。

後者がstyleに綺麗に追い出せているのであればcolorは物理名だけで済みます。


4. UIリソースは構造を設計するつもりで最初から正式名をつけましょう

icon1.png icon2.png photo1.jpgの様な仮リソース名は避けましょう。

「どの部分が画像でどの部分がxmlなのか」とか「このアイコンはPNG画像としては64x64でmarginに12dpを入れる」というレイアウト構造は最初から設計しておきましょう。

すぐれたxml drawableは開発量を大幅に削減します。つくらないが一番。

リソースリスト(pxサイズ、xml-drawableなのか9patchなのか等)は起こしながら、できれば正式なファイル名のダミー画像を全て用意してしまいましょう。


5. Activity/Fragmentの名前は必死に考えましょう

最初に間違うとコードリーディングコストが上がってじわじわボディブローの様に効いてきます。

また、"開発対象のシステム用語"と"Android用語"の混在に注意しましょう。例えば、機能名が「イベント通知一覧」だからと言って"EventNotificationFragment"の様な名前を採用するとAndroidのNotificationと混ざって首が絞まります。

追加メンバが特にやられます。HogeBackgroundService extends Threadみたいなclassができると面白い様にみんな同じところで死にます。


6. ActivityやインスタンスがユニークなFragment/Service/BroadcastReceiverはクラスヘッダを書き、歴史的経緯とUI仕様の参照元など、根拠インプットをコメントで必ず書いておきましょう。

名前やJavadocの概要で示せるのは「現在の実装に関する正確なコメント」です。開発序盤での検討経緯や、意図を残しておくと、開発中盤で「作っているものは変えられないけどサービスの方向性は結構変わってしまった」場合などになぜそんなことになったのか合点がいきます。同時に、捨ててもいいものなのかどうかの判定が容易になります。


7. Activity/Fragment構成はその時点での最終系にしておきましょう

よっぽど特殊なUIを採用しない限りたいていの「どこかで見たことがある」ユースケースの画面構成は既存のフレームワークでサポートされています。よって見た目が決まった時点で適切なActivity/Fragment構成は決めることができます。