Hatena::ブログ(Diary)

hdk_embeddedの日記 このページをアンテナに追加 RSSフィード

2014-10-14

mozilla Open Web Day in Tokyoにいってきたよ

03:39

Mozilla Open Web Day in Tokyo

ということで行ってきました。"Mozilla に関係する東西さまざまなコミュニティや研究プロジェクトが集結し、その成果の展示・発表を行う収穫祭的なイベント"らしく、文化祭のような雰囲気。懇親会まであり、たのしかった。

f:id:hdk_embedded:20141005130432j:image:w360

会場も体育館で文化祭っぽかったです。KDDIさんのOpen Web Boardが展示されていたり、大学の研究プロジェクトが展示されていたりと個人や企業だけじゃなくて公的な組織もおおくて意外にアカデミックな側面も。

展示では、Webとハードウェア割り込みをつなげてみたよ

Floppy Bird的なゲームとハードウェアデバイスをくっつけた"Balloon Jamp"の展示をしてきました。

f:id:hdk_embedded:20141014024021p:image:w400

大きなボタンの効果もあり、沢山の人があそんでくれた。よかった。利用デバイスRaspberry Piとわりとスタンダードなものを選んだのですが、ソフトウェア的には随分とキメラな構成になりました。

このデモでは、巨大なスイッチをGPIO経由で接続、GPIOの割り込みを検出してブラウザにイベントを(なるべく遅延ないように)送ってます。

OSとGPIO制御

OSはRaspbian(2014-09-09-wheezy-raspbian.img)を使用。ほんとはFirefox OSにしたかったのだけど、Raspberry PiFirefox OSのサポートレベルであるTiar 1〜4(数字が小さいほどパワーをかけてサポートされている)のいずれにも該当せず、完全に野良デバイス

Raspberry Pi向けのビルドコンフィグはあったのだけどHDMI出力で失敗してました。ざんねん。

./config.sh rpi
./build.sh

ちなみに、ターゲットボードをpandaboardにかえたら起動までは可能。ただし、こちらもやや条件があって、Firefox OS v2.0のブランチをつかってビルドしないといけなかったです。Issueにあるとおり画面(rotation)を90度傾ける問題があったり、マウスポインタが出ないなど実用上の問題があるので、手でpatchをあてます(自動でマージできないぐらいまでソースが進んでる)。

とりあえず今回はRaspbianつかったけど、https://wiki.mozilla.org/Foxberry_Pi_Demo のようにFirefox OSをRaspiむけに移植しようという動きがあるのでしばらくまってるとまともに動くようになるのかもしれません(しかし期待薄)。

Raspbianで、GPIOを制御しようとすると /sys/class/gpioあたりにぶら下がってるのでそのあたりをいじります。

echo  "7"  > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio7/direction
echo "1" > /sys/class/gpio/gpio7/value
echo "0" > /sys/class/gpio/gpio7/value

LEDのような単純なデバイスなら、コマンドラインから直感的に点灯/消灯を制御できます。以下のサイトがおもしろい。

あと、こういう直接的な手段以外に、GPIOを制御するためのコマンドもあるよ。

このあたり。インストールすると"gpio"コマンドが生えて、適当に制御できます。今回は未使用でした。

GPIOの割り込み通知

  1. LuaJITでGPIOの状態監視デーモンつくる
  2. GPIOの立ち下り、立ち上がり割り込みを監視
  3. 割り込みで起動したらスイッチイベントを作る
  4. 適当なキーイベントを作成して、LinuxのInput Sub Systemに投げつける
  5. キーイベントとしてブラウザが受け取る

f:id:hdk_embedded:20141014031712j:image:w360

キーイベントは日本語キーにない適当なものを仮想キー扱いでつくったよ。Raspbianのinputイベントは"/dev/input/event0"でした。

./input_key > /dev/input/event0

Cのプログラムでinput eventをゴリゴリつくります。コマンドとして投げます。このあたり興味あれば以下が面白いです。

- http://www.tatapa.org/~takuo/input_subsystem/input_subsystem.html

"Balloon Jamp"では、ブラウザにイベントを届ける、という作業が当初考えていたより手間がかかりました。たぶんもろもろがイレギュラー感あるシーケンスで無理やり達成した感じ。途中思ったのはイベント通知をWebSocket化できればよかった、ということなんだけど、画面更新しまくってブラウザをぶん回しているRaspberry Piさんは、CPU負荷が100%にはりついてしぬほど重い。WebSocketにした瞬間、ゲーム性もろとも死ぬとゴーストが囁いてた。

キーイベントなら取りこぼしもなく、ちゃんと伝わる。すごい(Linuxの歴史を感じる)。

JavaScriptからGPIOを読み取るライブラリはいくつかあったのだけど、ポーリングのような仕組みしか作れず、押してる瞬間に読み取れるとも限らないのでスイッチには対応しきれない感じ。このあたり良いライブラリがあれば良かったのだけど(見落としてなければ)。

非力なCPUや環境でブラウザハードウェア的なイベントを送るには、という観点で頑張ったら、わりと面白い構成になったので制作記的にのこしておくことにしました。

トラックバック - http://d.hatena.ne.jp/hdk_embedded/20141014

2014-07-25

Android Open Textbookプロジェクト milestone1 「出かけよう、Android!」リリースのお知らせ

| 04:14

かねてから取り組んできたオープンソース本「Android OpenTextbook」プロジェクトの最初のマイルストーンができました。今回はその紹介です。

f:id:hdk_embedded:20140725035020p:image:w480

記事の最後にPDFダウンロード先(無償)と書籍版(同人誌頒布)の案内があります。興味があれば是非、読んでみてください。

Android OpenTextbook(AOTB)の概要

Android OpenTextbook(AOTB)は、GitHubと書籍制作ツールRe:VIEWを利用して開発者が欲しい技術情報を集約する試みです(TechBooster.orgの該当記事)。

f:id:hdk_embedded:20140725040155p:image:w360

Android OSは公開以来、アップデートが繰り返されてきました。Google I/O 2014で発表されたAndroid "L"のように常に新しい技術を取り込んで進化しています。

個人的にはOSの進化をワクワクしてみてます。それはAndroidのみならず未知の分野、技術に触れる楽しみがあるからですが、このあたりは、このブログに興味を持ってくれたエンジニアのみなさんはわかってもらえそうな気がしています:)

一方、新規参入するアプリ開発者としては嬉しい事ばかりではありません。参入者が覚えることは思いの外、多くなっています(こういう傾向は、何もAndroidに限った話ではないんだけども…)。

Android OpenTextbookでは、Androidアプリ開発を始めるにあたり必要な情報をオープンソース化して教科書として運用することで、常に最新の情報にアップデートをかけていこう、という試みです。そしてこの数か月の成果として最初のマイルストーン、AOTB m1ができあがりました(m1は、milestone 1の意味です)。

AOTBプロジェクトのかたち

次の図のような構成でAOTBプロジェクトは進んでいます。

f:id:hdk_embedded:20140725034844p:image:w640

赤い項目が、m1で対応した内容、赤枠に白背景の項目がm2(マイルストーン2、2014/12目標)にむけて進めている項目です。破線で囲まれた項目は、必要だと感じているが、現在着手できていないカテゴリです。

→の方向にスキルツリーが構成されており、ふつうに属しているカテゴリは、やさしいに属しているカテゴリを把握したうえで読んでほしい、という意図があります(が、そんなに厳密でもなく、分野ごとに凸凹している、目安みたいなものです)。

実際にこの内容を使って、Tech Instituteという早稲田大学さんで実施されているプログラミングスクールで利用していく予定です。プログラミング教材として運用していく中で、より良いものに改善したいです。

AOTB m1「出かけよう、Android!」の紹介とPDF無償公開

無償PDFダウンロードはこちらから(入稿前版です。ところどころ校正が済んでないので、このあとの正式なリリースをお待ちください…)。

AOTB m1のメインターゲットは、開発初心者です。サブターゲットは中級者や他の分野からコンバートしてアプリ開発者になったひとが必要になった時に確認できるような副読本としての利用です。

中級者のひとであれば、上記PDFの3章センシングデバイスの項目を読んでみてください。非常に入り組んだAndroidのセンサー事情がわかりやすく書かれています。初心者のみなさんは1,2章のUIについてや、4章のネットワークプログラミングを読んでみてください。ネットワークの基本からAndroidでの使い方までとても丁寧に書かれています。

今回の「出かけよう、Android!」では、UIコンポーネントの入門やネットワークプログラミング、センサー、3Dグラフィックなど多くの分野をカバーしています。プログラミングを学ぶ際の副読本としてご利用ください。



紙の書籍の頒布についておしらせ

書籍としては、コミックマーケット86 3日目(8/17) 西か46b TechBoosterで頒布予定です。当日会場に来れないひとも多くいるとおもいますし、欲しいひと全員に届けたい、という気持ちがあり、事前予約サイトを用意しました。

デジタルでなく紙版が欲しい、という方は以下サイトよりご予約、またはコミケ当日の頒布で入手お願いします…!予約分は、一冊一冊、梱包してラベルを張って発送します…!

  • Booth.pm(予約販売サイトです)

f:id:hdk_embedded:20140725014244j:image:w360

また予約受付は入稿の関係で期間限定です。諸条件ありますので詳しくはサイトをご確認ください。今回は特にデジタル版を無償配布する(しかもコミケよりも先に)ので当日部数は、かなり少な目です。デジタルファースト、という初めての取り組みなので頒布部数が読めません。実際、予約状況をみて印刷部数を決めるので予約が集まれば集まるほど嬉しいです。


常に最新のPDFを入手できるようにCI環境を構築して、運用しています。

今回、AOTBプロジェクトでは、常に最新のビルドが提供できるようにCI環境を用意して運用してます。CIサーバから常に最新のPDFを受け取ることができます(リリースを待たずに、アップデートに追従できます)。

現在は特に作っている最中のため、m1のあともすぐに章が追加されm1_r1が出る可能性が高いです(こういう変なところはAndroidを真似なくてもいいのですが、開発初期ということで安定しだすまで許してもらえると嬉しいです…)。

安定板(m1,m2)については個別にダウンロードリンクを用意しますが、最新版がほしいよ、という方はこちらのCIサーバからダウンロードしてください。

また、このCIサーバは大変便利なのですが、動作が不安定です。突然メンテがはいったり、不具合があったりするかもしれません。あらかじめ、ご了承ください。

どんなふうに動いてるの?

CI環境について、PyCon2014で(開発担当のあめだまが)講演します。

基本的には執筆者が便利だからCIサーバーを用意したのが始まりなのですが、モリモリと機能が増えていきました。Re:VIEW記法で書かれた原稿をコンパイルして確認用PDFをつくるところまで責務です。どんなふうに動いてるの?という部分に興味がある人は、是非。

フィードバックについて

最後に、お願いです。実際のところ、AOTB m1は文字通り、マイルストーン1で、完成ではない状況です。教科書として体系だった学びを提供するには、カテゴリごとの点を体系としてならべたり、足りないカテゴリを追加したりと次のミッションがみえてきています。もしコントリビュートを考えている方がいらっしゃれば以下のようなことをしてもらえると嬉しいです。

  • 誤字脱字、日本語としておかしな箇所を見つけたらPR( https://github.com/TechBooster/AndroidOpenTextbook )を送ってもらえると助かります(マージするだけだとすごく手間が省けます)。
  • この章ならかけるよという箇所があれば、是非、@mhidakaまでご連絡ください。
  • 文章の編集や紙面のレイアウトなど編集作業を手伝ってくれる人が居たら泣いて喜びます。
  • 新人さんに勧めてみて話のネタにしつつメインターゲットとなる人の感想を教えてください。
  • 紙版が欲しい人は積極的に購入いただけるとうれしいです(配布部数によってはm2でのリリースはデジタルだけにするかもしれないので)。

品質についても「Effective Android」やその他書籍制作で培った技術をフル活用していますが、中々、手が足りていない現状です。書籍、EPUBとしてのレイアウトや編集などでも手伝ってくれるひとがいると、すごくうれしいです。

トラックバック - http://d.hatena.ne.jp/hdk_embedded/20140725

2014-06-23

手のひらサイズ、少し未来のAndroid Botの作り方

| 03:51

面白いOSSプロジェクトを見つけたので紹介します。コンセプトは手のひらに乗るBotSiriやGoogle Nowのような対話型のインターフェイスを自分でも作れる面白さがあります。

Botとは

最近、hubotのようなBotが流行っていますが、Botチャットを通じたメンションなどでコマンドを受け付け、コマンドの種類に応じた処理を実行して結果を返す単純な仕組みで動いています。

hubotに代表されるBotはプロダクトをビルドしたり、画像を探して来たりと簡単なお使いができるため、プロジェクトでもお馴染みの存在となりつつあります。

AndroidBotにする"robota"プロジェクト

今回みつけたrobotaはhubotとは少し毛色が異なり、Androidシステム上にアプリやServiceとして動作する「手のひらに乗るBot」です。

ちょっとわかりにくいと思うので図にしてみました。

チャットを経由してAndroid対話できるシステム

f:id:hdk_embedded:20140623023205p:image:w480

簡単にいうとIdobataというチャットシステムを経由してBot(Androidアプリケーションとして動作している)と対話が可能です。

echoしてみる

実際にチャットからみるとただのBotにしかみえません。Idobataからechoすると次の通り。

f:id:hdk_embedded:20140623023815p:image

ちゃんと「私は羊だ」とechoが帰ってきてますね。いままではビルドサーバーなどでお守りをしていたBotAndroidサイズに飛び出した、というわけです。


"robota"で何ができるの?

Android端末上でアプリケーションとして動作できるので、アプリで出来ることは何でも。今までのAndroidアプリ資産が沢山あるのでおおよそ思いつくことはすぐに実装できちゃいます。

  • 今の気温を確認する(端末のセンサを使ってもいいし、ADKでも)
    • 私の発言:@Nexus5 やぁ、ネクサス、今の気温は?
    • Botの返信:自宅の気温は 25度です。少々熱いですね
  • 部屋の写真を撮ってもらう(カメラを使って)
    • 私の発言:@Nexus5 ネクサス、飼っているインコの様子が知りたいな
    • Botの返信:少しお待ち下さい。良い表情が撮れるよう試してみますね
  • IR-Kitを使って。
    • 私の発言:@Nexus5 もうすぐ家に着くよ、エアコンをつけておいてくれないか?
    • Botの返信:わかりました。冷房を効かせておきます

監視系でもこれぐらいの用途はすぐに出てきます。自分の端末にBot住まわせておけばこんな使い方もできるでしょう。

  • お使いに
    • 友人の発言:@Nexus5 mhidakaにコーヒーを忘れないように買ってくきてほしい、と言づけてくれないか?
    • Botの返信:わかりました。通知バーに「コーヒーを買う」と固定しておきました。あとは神に祈りましょう。グーメン。

これなら買い忘れてもBotのせいにできるかも…?

robotaを触ろう。

robotaは本体とルール生成エンジンに分かれており、実装は非常に簡単です。なぜならIdobataとの通信や待ち受けなどルール部分以外はrobotaのcore部分が受け持っているため、開発者はルールを作ることに集中できるようになっているからです。

f:id:hdk_embedded:20140623025107p:image:w480

端末にインストールされたrobotaはIdobataのメンションを受けてブロードキャストを行います。自分が作ったアプリケーションで処理し、応答をrobotaに返信すると、Idobataへの投稿含めてrobotaが残りの処理を実施します。

もともとAndroidに備わったブロードキャストレシーバーを使ったわかりやすい実装と言えるでしょう。次はrobotaをインストールしてサンプルコードを動かすところまでを解説します。

インストール

robotaのインストールはとても簡単ですが、いくつかUI上の注意点があります。順番に説明していきます。

robotaをインストールすると、電源ボタンが表示されます。初期状態はOFFなので、真っ暗です。

f:id:hdk_embedded:20140623025717p:image:w240

ちなみにタップするとすぐにONにできますが、Idobataとの連携が済んでないので、まだ意味がありません。OFFにもどして順番に作業しましょう。

f:id:hdk_embedded:20140623025714p:image:w240

Settingsを開くと、BotのToken追加と、インストール済みのルール、Aboutの3つがあります。

f:id:hdk_embedded:20140623025710p:image:w240

Botをタップしてひらいた画面ではIdobataで取得できるトークンを記入しましょう。ここは手打ち上等なのですが、エンジニアらしくコピペなりadb inputなりして手間を省いてください。

f:id:hdk_embedded:20140623025707p:image:w240

Settingsの"Installed engines"では、ルールがちゃんとインストールできているか確認できます(ただし権限の確認までは行われないため、後述するAndroidManifest.xmlに注意)。

f:id:hdk_embedded:20140623025704p:image:w240

IdobataでBotを追加する方法

Idobataでは部屋のROOM SETTINGSからBotを追加できます。設定画面内、Add Botを選択するとボットの作成画面に遷移します。

robota対応ルールの作り方[Hello! robota!]

ここからはrobotaに対応したアプリケーションの作り方を紹介します。メンションを受け取ったらどんなことにも"Hello!"と元気よく挨拶するルールを追加してみましょう。非常に簡単な構造ですので安心して読み進めてください。

Android Studioで依存関係を解消する

まずはrobotaを使うためのライブラリを選択します。Gradleで

  • compile "com.uphyca.robota:robota-engine-core:${robotaVersion}"

と設定してください。

例えばv0.9.1を指定するのであれば次の通りです。

dependencies {
    compile 'com.android.support:appcompat-v7:+'
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile "com.uphyca.robota:robota-engine-core:0.9.1"
}
HelloEngine.java

ルールを記述してみましょう。com.uphyca.robota.engine.EngineBaseクラスを継承してEngineを生成します。

このEngineBaseクラスはブロードキャストレシーバーが元になっており、Botとして利用可能な要素に加工した状態で引き渡してくれます。

public class HelloEngine extends EngineBase {

    @Override
    protected String onMessageReceived(Context context, Bot bot, TextMessage textMessage) {
       return "Hello!";
    }
}

botインスタンスにはBot情報が、textMassageインスタンスには発言者情報が格納されています。このHelloEngineでは、一切のメッセージを無視して"Hello!"と返信します。

シンプルですね。なお、発言者のメッセージを加工する方法はEngine-bundleのEchoEngineなどがわかりやすいです。

AndroidManifest.xml ブロードキャストレシーバーの登録

最後にブロードキャストレシーバーの登録です。このあたりは普通のAnroidアプリケーションと変わりません。インテントフィルター名が固有なので、ここだけ間違えないように注意してください。

    <uses-permission android:name="com.uphyca.robota.permission.RECEIVE_MESSAGE_CREATED"/>

    <application>
    ...省略...
        <receiver
            android:name="org.techbooster.sample.robota.helloworld.HelloEngine"
            android:label="@string/label_hello"
            android:description="@string/description_hello">
            <intent-filter>
                <action android:name="com.uphyca.robota.action.MESSAGE_CREATED"/>
            </intent-filter>
        </receiver>
    </application>

uses-permission要素を忘れるとブロードキャストレシーバーを受け取れません。


またlabelとdescriptionについてはCDATAセクションです。たとえば次のようにString.xmlに記述します。

<?xml version="1.0" encoding="utf-8"?>
<resources>

    <string name="app_name">Robota</string>
    <string name="hello_world">Hello world!</string>
    <string name="action_settings">Settings</string>

    <string name="label_hello"><![CDATA[${bot_name} hello ]]></string>
    <string name="description_hello"><![CDATA[Reply back with hello]]></string>
</resources>
動作確認

f:id:hdk_embedded:20140623033530p:image:w640

great good! :)

Botの将来

hubotをみていて思ったことはビルドやプロジェクト管理に便利なのはもちろん、hubotとの会話を楽しめる、ということです。まるでチームに友人が増えたかのような賑やかな雰囲気に変わる、しかもhubotがビルドエラーしちゃったら「まぁしょうがないよね」と人ではなく「何がビルドエラーの原因か」という問題と向き合えるようになります。

たとえばデスマをしていれば人間同士ではミスを許しあうことも難しいかもしれません。「〜さんのコミットでビルドが壊れた!」なんて脳裏を過ると、精神衛生上良くありません。

今回紹介したrobotaのようなプロダクトはAndroidなど手のひらの機械に一種の人格を与えることができる、面白い試みだと思います。SiriやGoogle Nowなどを見てもわかるように、コンピュータにもサジェスト機能がどんどんと盛り込まれています(古くはiコンシェルのようなものもあるので発想自体が新しいわけではないでしょうが)。

手のひら大のコンピュータを自分に合ったかたちにカスタマイズする、という試みはコンピュータとの付き合い方を面白く変えるキッカケになりそうですね。

トラックバック - http://d.hatena.ne.jp/hdk_embedded/20140623

2014-06-21

C86注目の技術書サークル一覧

| 00:16

既存の情報からコミケ3日目(8/17)、同人ソフトソフトウェア技術書という観点で注目のサークルをまとめました。抜け漏れありそうだけど自分用のメモ、ということで。随時追加していきますが、Twitterでメンションしてもらえればメンテします。

TechBoosterの参加告知(日曜日 西か46b)

サークル「TechBooster」もコミケに参加します。日曜日 西か46b に配置されました。

頒布予定は以下3冊を予定してます。搬入の都合上、部数は少な目な気がします。よろしくおねがいします。

f:id:hdk_embedded:20140621234605p:image

  • Android初心者本(仮)
    • 教科書本。なベストプラクティス総まとめ的内容にしたいなー、できるかなー、というところです
  • FirefoxOS本(仮)
    • FirefoxOSの最新情報をまとめつつ、既存の本ではフォローアップできてない最新版でのアプリ作成方法など
  • Android上級者本(仮)
    • 書きたいことだけ書きました!的、面白本。多分、Android 5.0的ネタもこっち。興味あるなー、という分野を容赦なく紹介していきます。

の3冊です。まだ影も形もありません。中身、ゲスト等は完成後に告知しますので続報は https://webcatalog-free.circle.ms/Circle/11316947 や techbooster.org でお待ちください。

注目の技術書サークル

サークルチェックの結果を怒涛の勢いで紹介!(毎度のように店番なので買えないのが悲しい)。今回は技術島は1つではなく、西ホールの「か」「き」島に分散配置されてるっぽい。紹介は「か」の後ろからぐるっとまわって「き」まで一周する順番。発行部数は各サークルさまごと違うので、買えなかった!などの苦情は受け付けません。欲しければ並ぶのだ、勇者よ!

くずかごのーと / 日曜日 西か46a
JCROM Project / 日曜日 西か44a
つ部 / 日曜日 西か43b
Tech-orz / 日曜日 西か41b
Applest / 日曜日 西か38b
COMFRK / 日曜日 西き38b
アトリエのどか / 日曜日 西き33b
日本Androidの会Unity部 / 日曜日 西き28b
YUGA / 日曜日 西き27b
参照透明な海を守る会
Metro Girl / 日曜日 西き26b
glenda9 / 日曜日 西き20b
AliceSystem / 日曜日 西き20a
低級はっかーズ / 日曜日 西き10b
トラックバック - http://d.hatena.ne.jp/hdk_embedded/20140621

2014-05-23

Google+アプリに新しいデザインが来たのでGoogle I/O 2014で発表される新Androidバージョンでのデザインガイドラインを推測する遊びをしてみた

| 04:12

2014年5月23日、G+アプリに更新があるというので試してみたら既存のデザインガイドラインに無いロックな挙動をしていたので紹介します。

1か月後にはGoogle I/O 2014を控えているこの時期の更新、ということで新しいAndroidバージョンに取り込まれるのだろうなー、とか推測しながら挙動を書き留めました(私自身、すぐ慣れてしまうので忘れないように)。

先にまとめておくと次の通りです。

まとめ

  • カードUI最適化した一例としてG+アプリをみると良い
  • ActionBarの機能拡張、ブランドカラーの強化
  • ListView(カードUI)の上部にメニューをだす形が流行りそう
  • いままでもGoogleは自らデザインガイドラインを破ってきたし、時代に合わせて新しいガイドラインに更新している

今回に限らず、Googleアプリでは、アプリごと思想が微妙に違ってるケースがあります。Google+GmailGoogleドライブなどアプリごと細かい部分での挙動を統一しきれないこと自体は珍しくないので、まぁそんなもんです。

想像力を膨らませながらデザインの新しそうなところをまとめたので(実際の意図は設計者に聞かないと分からないものですが)読んで気になったところ、デザインの意図とか、あーだこーだ周りの人と議論すると面白いと思います。

NavigationDrawerは、死んだ。

Android開発者なら、アプリを立ち上げて、いくつか気になる点があると思います。

f:id:hdk_embedded:20140523023852p:image:w600

ActionBarの高さが微妙にデカいこと、NavigationDrawerが廃止されていること、投稿ボタンを下に置いてあること。

ActionBarのブランドカラーやサイズ感などでしっくりこないかもしれませんが、ActionBarには「更新しています…」など状態表示も含まれるようになっています。

今回、特に注目したいのは、NavigationDrawerでのメニュー表示を廃止してしまったことです。

実際のメニューはどのように表示されるかというと

新しいメニュー

f:id:hdk_embedded:20140523023853p:image:w600

Google+では、このようにListView(カードUI)の上にメニューをもってきてます。ListViewの上部にメニューを表示する手法は、わりと最近に見かけるようになってます。流行に乗っかってる感じがしてますね。

従来のデザイン

ちなみに現在のガイドラインに沿うなら次のようなデザインが一般的です。

f:id:hdk_embedded:20140523023854p:image:w600

こちらはNavigationDrawerを採用したタイプで現在位置をTabで表示して左右スワイプでカテゴリを移動するスタンダードなタイプです。

デザイン変更の理由は?

もともとG+の旧アプリも、このようなをNavigationDrawerを持ってましたが今回の更新でバッサリ変更となりました。理由としては

  • カードUIとしての操作性の統一

がありそうです。最近のモバイルアプリでは、左スワイプを別の動作にあてることがあります。たとえばGmailアプリではスワイプはアーカイブにあたり、Google Nowではスワイプはカードの非表示です。

左右スワイプの使われ方が、カテゴリを移動する、から派生して、いろんな操作を意味することになった点が大きいかも。

これらの操作と混同することを防ぐためにはNavigationDrawer以外のほうがよいのかもしれません。

NavigationDrawerは消え去るのか?

死んだ、と言ってしまいましたが実際はそんなことはないです。NavigationDrawerのメリットは画面端からのスワイプで、いつでもメニューにアクセスできる点ですし、複雑な操作を一手に引き受けてくれます(メニューの出し方がわかりにくくチュートリアルが必要だったり沢山あるメニューから正確なアイテムを取り出せるか、など議論の余地はありますが)。

現状、すぐになくなってしまうデザインパターンとは言いにくい状況です(つまり、まだ主流)。今後のトレンドをみつつ採否を考えていけばいいかと。

Google+で、NavigationDrawerを廃止した理由は、画面ごとに何をすればよいか、という分かりやすさがほしかったからかもしれません。利用シーンにあわせてメニュー(またはコンテンツ)を表示すると、何ができるかわかりやすく伝えらえると考えたのかも。

右側から出てくる通知領域

NavigationDrawerは左側からでてきましたが、Google+の通知領域は右からでてきます。

(13:58 追記:今回のアプデではなく以前からこの挙動のようです)

f:id:hdk_embedded:20140523023857p:image:w600

これは驚いた。定着するかはちょっとわかりませんが、右スワイプが余ってる(※左スワイプはカードの削除や非表示に割り当てられている)ので何か使ってみたかったのでは…。ちなみに通知領域が画面右側に寄って出ること自体はウェブGoogleウェブページでは右上にアイテムが集中してるので)でよく見るので普通の発想かなー、と思います。

そういえばFacebookアプリも以前は右側をスワイプするとアクティブな人リストがでてきてましたね(FBのほうは新デザイン移行に伴い、でなくなっちゃいましたが)

邪推すると…

Webと同じ操作系にしてくるってことは、やっぱりAndroid 5.0ではChromeAndroidが統合されるのだなー、とか考えると夢が広がります(反論をあげておくと、モバイルでWebと似たような操作系を採用すること自体は、珍しくはないという気もしますね)。

ブランドカラーの扱い方

ActionBarはアプリのブランドカラー(Google+なら赤)がはいります。また今までよりActionBarは背が高くなっており、存在感が増しています。かわりにメニューなどはListView(カードUI)をスクロールさせれば非表示になるなど画面を有効に使う工夫がされています。

f:id:hdk_embedded:20140523041836p:image:w600

個人情報のページではブランドカラーが個人のカバー画像で入れ替わるように工夫されてます。一方、画面左上の「<G+」という戻るボタンなどは今までのデザインガイドラインを踏襲してます。

ActionBarのブランドカラー変更や背が高くなったことを考えるとActionBarの役割が拡張されているのがわかります。

下ボタンUIが復活しそうな気配がある

どうも画面下部の扱いが見直されている気がします。

というの画面下に投稿ボタンが置かれてるからです。G+のアプリ画面を見ると投稿ボタンが下に移動しています。

f:id:hdk_embedded:20140523023855p:image:w600

いつもなら画面上部に置くはずのボタンが下にあります。さらに投稿画面をみてみると、やっぱり投稿ボタンが下に移動しています(下図)。

f:id:hdk_embedded:20140523023856p:image:w600

現在、一般的なアプリだと画面右上に投稿ボタンを配置しています(図の右)。しかし新G+アプリでは画面右上が空いてるにも関わらず画面右下に統一しています。明確な意思が感じられるなー、と。あとデフォルトキーボードを非表示にしているあたりもポイント高いですね。

かわりに画像やカメラ(しかもプレビュー付)での写真を選びやすくしています。これはSNS(とくにGoogle+)が画像中心になっている現状を踏まえて、優先度を文字から写真にスイッチしたのでしょう。

デザインガイドラインは変化するもの。

以前、Googleはこういっていたと記憶してます。「画面下はホームボタンやバックボタンとかあるから下タブとかやめていこう!」しかし、日は流れ、スマートフォンのサイズが4インチを超え、5インチ超も当たり前となりつつあります。

ぶっちゃけ画面上だともう指が届かないので下に持ってくることを是としたと思います。

投稿ボタンも画面下、ホームボタンのすぐそばにおかず、少し上部に離して配置していることからも、ユーザーへの誤クリック防止の配慮がみてとれます。

デザインガイドラインを守るのも大事ですがユーザーの立場にたって考えることも重要ですね、みたいな話なのですがGoogleはわりと自分でデザインガイドラインを破ってきます。

日々ガイドラインを守れ守れと言っておきながらなので手のひら返しにみえますが、

「ユーザーにとって何が一番いいか」という試行錯誤は個人の開発者ではやりにくいのも事実です。今回の変更も新ガイドライン化されるかもしれないし、ユーザーの受けが悪ければ、何事もなかったかのように消えるだけかもしれません。

まとめ

ガイドラインは時代や流行りと共に変わる点に留意しておくこと。ただし、基本はガイドラインに準じるとデザインの観点からもコストパフォーマンスが良いはず。やはりユーザーが操作に迷わないというのは強い。

あとこの新ガイドラインを推測する遊びは多分こういう意図だろうなー、と思ったことをざっくり書いただけです。次のデザインガイドラインはこれだー!とか信用せず、Google I/O 2014を楽しみに待ちましょう。

トラックバック - http://d.hatena.ne.jp/hdk_embedded/20140523