2014/02/16

Xperiaカメラアプリ作成 その1

前回のエントリーで昨年は家電をたくさん買い換えたみたいな話をしましたが、最近ほぼ同時にテレビとHDDレコーダも壊れてしまい、引き続き今年も家電を買う流れは止まらないみたいです(笑。それにしても最近の家電はスゴイなぁと約10年振りにテレビを買い換えて改めて思いました。

さて超久し振りに技術ネタでも書いてみようと思います。Xperia Z1からカメラアプリにプラグインで外部アプリを追加できるような仕組みが提供されました。この機能は海外版のXperia ZやZ UltraにもAndroid4.3へのバージョンアップと共に提供されてます。今回はこのXperiaのカメラアプリ作成を取り上げたいと思います。

■開発環境のセットアップ
カメラアプリ作成用のSDKがCamera Add-on APIとして提供されてますので、これを使えるように開発環境をセットアップしましょう。

Android SDK Managerを立ち上げて、ToolsメニューからManage Add-on Sites...を選択し、User Defined Sitesに以下のURLを追加します。

http://dl-developer.sonymobile.com/sdk_manager/Sony-Add-on-SDK.xml

そうすると、Android 4.1.2用の追加パッケージとして、Sony Add-on SDKが選択できるようになっているはずなので、インストールします(下図は既にいろいろインストール済の状態ですが、最新のSony Add-on SDK2.1だけをインストールすれば問題ありません)。


Sony Add-on SDKをインストールすると、今回取り上げるカメラアプリ用以外にもスマートウォッチ用やSmall App用のSDKが提供されますので、これらに関してもいずれ取り上げたいと思います。

また、Camera Add-onに対応したアプリの作成に関しては、UIのガイドラインなども規定されており、こちら(リンク)からAdd-onの仕組みも含めかなりしっかりとしたドキュメントがダウンロードできますので、一読しておくことを強くお薦めいたします。英語ですが。。

■サンプルカメラアプリ
AndroidのSDKをインストールしたフォルダーを$ANDROID_SDK_HOMEだとすると、$ANDROID_SDK_HOME/add-ons/以下にadd-onとしてインストールしたパッケージがあり、Sony Add-on SDKもここにあります($ANDROID_SDK_HOME/add-ons/addon-sony_add-on_sdk_2_1-sony-16/)。

このフォルダーの中にCamera Add-onのサンプルアプリがありますので($ANDROID_SDK_HOME/add-ons/addon-sony_add-on_sdk_2_1-sony-16/samples/CameraAddon)、この中のMultiFunctionCameraAppSampleをEclipseにインポートしましょう。

MultiFunctionCameraApp.javaがアプリ本体で、CameraTask.javaはカメラのプレビューを表示するSurfaceViewを管理する為のSurfaceHolderです。

MultiFunctionCameraAppアクティビティーには3つのImageButtonがあり、ひとつはカメラのシャッターボタン(@+id/capture)、もうひとつは最新の写真/動画を表示する為のサムネイルボタン(@+id/thumnail_button)、そしてCamera Add-onアプリを選択する為のメニューを表示する為のモード選択ボタン(@+id/button)です。

このCamera Add-onアプリを選択する為のメニュー(下図)を制御する為のクラスがCapturingModeSelectorです。


これをアプリの中に組み入れればいいわけですね。

初期化のコードはアクティビティのOnResume()メソッド内になります。
try {
  Class.forName("com.sonymobile.camera.addon.capturingmode.CapturingModeSelector");

  // Create a parent view for the capturing mode selector view.
  ViewGroup modeSelectorContainer = (ViewGroup)findViewById(R.id.modeselector_container);

  // Create a CapturingModeSelector
  mCapturingModeSelector = new CapturingModeSelector(this, modeSelectorContainer);

  // Set two listeners on the CapturingModeSelector
  mCapturingModeSelector.setOnModeSelectListener(new MyOnModeSelectListener());
  mCapturingModeSelector.setOnModeFinishListener(new MyOnModeFinishListener());
} catch (ClassNotFoundException cnfe) {
   // If the camera add-on library is not found (Camera add-on API not supported),
   // implement suitable exception handling.
   Log.e(TAG, "Camera add-on library not found. Handle the exception, eg. finish the activity.");
   cnfe.printStackTrace();
   finish();
} catch(SecurityException se) {
   // If a SecurityException (Insufficient privileges) is caught,
   // implement suitable exception handling.
   Log.e(TAG, "Camera add-on permission not granted. Handle the exception.");
   se.printStackTrace();
   showPopupReinstall();
}
Camera Add-onのライブラリーが存在するかどうかを調べ、CapturingModeSelectorをインスタンス化して2つのリスナーを設定しています。また、Camera Add-onをアプリで使用するには、AndroidManifest.xmlファイルに以下のパーミッションを設定する必要があります。
<uses-permission android:name="com.sonymobile.permission.CAMERA_ADDON"/>
以下がCapturingModeSelectorクラスのパブリックメソッド一覧ですが、詳細はこちら(リンク)を参照してください。
voidopen(モード名)
CapturingModeSelectorを表示します
voidclose()
CapturingModeSelectorを閉じます
booleanisOpened()
CapturingModeSelectorを表示していたら真を返す
voidsetOnModeSelectListener(コールバック)
CapturingMode選択時のコールバック
voidsetOnModeFinishListener(コールバック)
CapturingMode選択時のコールバック
voidsetUiOrientation(int orientation)
画面のオリエンテーションを設定
voidrelease()
CapturingModeSelectorを破棄します

setOnModeSelectListener()とsetOnModeFinishListener()と2つコールバックの設定ができますが、これの使い分けはユーザが選択したモードが選択前と同じパッケージ名・アクティビティの場合にsetOnModeSelectListener()が呼ばれます。

つまり大雑把に言うと、自分のアプリに処理が戻って来る場合はsetOnModeSelectListener()が呼ばれ、違うアプリに遷移する場合には、setOnModeFinishListener()が呼ばれます。以下それぞれのコールバックの処理部です。

setOnModeSelectListener()
public void onModeSelect(String modeName) {
  mCapturingModeSelector.close();
  setViewsVisibility(View.VISIBLE);
  setThumbnail();
}
自分のアプリに戻るので、CapturingModeSelectorを閉じてViewの再設定をしています。

setOnModeFinishListener()
public void onModeFinish() {
  mCapturingModeSelector.close();
  finish();
}
他のアプリに遷移するので、CapturingModeSelectorを閉じて、アプリを終了しています。

で、ソースコードを見てみると基本的にCapturingModeSelector周りのコードはあまり弄る必要が無いことがわかります(モードボタン等の選択に応じたメニューの表示/非表示や画面のローテーションに応じた画面オリエンテーションの設定をしているだけ)。なので、Camera Add-onに対応したカメラアプリを作るには、このMultiFunctionCameraAppのソースコードを雛形に使えば良さそうです。

と言うわけで、次回以降このコードをベースにCamera Add-on対応アプリを何か作って行きたいと思います。

2013/12/24

スマホセントリックで生きましょ

どうもまたまたご無沙汰してますた。Rebootしたつもりがすっかり起動に失敗してたみたいです (^_^; ってか、仕事に慣れたら慣れたで色んな仕事をふられてしまいまして・・そこはそれブラック企業ですからw。

ってことで、来年こそは何かアウトプットを出さねばヤバイと思いながら今年を総括する的なエントリーをば。

まぁ、何と言っても自分の今年の一番大きな出来事は転職なわけですが、小さな出来事としては今年は例年になく家電を買い換えた1年でした。花粉症の時期も快適に過ごせるようにJetClean(あれ、AirEngineに名前変わってる?)を購入したのを皮切りに(いや、まぁ買ったのが微妙に遅くて効果をいまいち感じ取れなかったのが今では良い思い出ですけどw)、梅雨の衣類乾燥や夏場の除湿に大活躍してくれてた除湿機も古くて重くて部屋間の移動に難儀してたからカンキョーの最新型に買い替えました(いや、これ軽くてマジでお薦め)。

その後は家の電話を、スマホを子機に使えるPanasonicの電話機に買い換えました(いや、これスマホで(電話機を通して)通話が出来たり留守録が聞けたり便利は便利なのですが、微妙に残念だったというか今後に期待したいのは、FAX機能ですね。FAXをPDFに変換してスマホで見れたり、あと常時wifiにつながっているのが前提なのだとすれば、登録してあるメールアドレスに留守録を音声ファイルにして添付ファイルで転送してくれたりする機能があるとパーフェクトなのですがね)。

最後は最近俄然興味が出てきているハイレゾ音源を再生できるようにシステムステレオをHAP-S1に買い換えました。コストを抑える為かアンプは最新のデジタルアンプであるS-Master HXじゃなくて何とアナログアンプらしいのですが、自分的にはこれがむしろ良かったというか正解だったように思います。イメージだけかも知れないけど、何となく音が柔らかい気がするし、まだエージングが終わって無いスピーカーもこれからに期待感を抱かせてくれるに充分な鳴りがしてます。

個人的にはピアノの響きが好みだったのと管弦楽器が耳障りな音色じゃなかっただけで満足なのですが、基本的にはあっさりした味付けなので人によっては物足りないかも知れません。間違いなくハードロックやディスコミュージックを聴くよりは、Natalie ColeやNorah Johnesとかのしっとりとした女性ボーカルを聴く方に向いてる気がします(つまり自分好み)。

で、手持ちのCDをせっせとリッピングして聴いてますけど、ハイレゾじゃない音源でも高音質化するDSEEの効果がどれほどのものか気になる人もいることでしょう。自分的にはCD(44.1kHz/16bit)の音源はプラシーボくらいの違いしか感じませんでしたし、圧縮音源はDSEEで補正したところで、あまり満足できる音ではありませんでした(ってか、普段はスマホで圧縮音源を聴きまくっているのに勝手なもんですよねw)。DSEEの効果を感じるには上位機種のHAP-Z1ESか、もしかしたらヘッドフォンでじっくり聴いた方がいいのかも知れません。

そして、サンプルで幾つかハイレゾの音源が購入時から入っているのですが、これは流石に一段とレベルが違う音がします。音の広がりの違いが自分程度の耳でもはっきりと聴き取れます。これを体感してしまうともう全てハイレゾで楽曲を揃えたくなってしまいますが、それにはお金がかかってしゃーないですね(メーカーの思う壺なわけだw)。ただ、いまだとHAP-S1とスピーカーのセット購入でmoraで使える2万円分のクーポンがもらえるキャンペーンをやっているので、少しお得です。

あとこれ、スマホやタブレットで操作できるアプリが用意されているんですよね。この手の機器は楽曲が増えた時の操作性がいつも問題になると思うのですが、スマホやタブレットなら大量の楽曲の閲覧も容易だしプレイリストも含めて管理できます。それと、なかなかの優れものだと思うのが楽曲を解析して自動で分類する「おまかせチャンネル」という機能です。楽曲が増えるとプレイリストでの選択すら面倒に感じる自分には、その時の気分でチャンネルを選べば自動で選曲してくれるこの機能はぴったりです。

それにこのアプリ、UIがXperiaのWalkmanアプリと共通しているので、ユーザーの自分には買ったその日から何の違和感もなく使えました。人によってはこういう微妙な囲い込みが気になるのかも知れませんけどね。

とまぁ、ステマ全開?のエントリーですが、残念な部分が無いわけではありません。まず最初に気に入らないのは、インターネットラジオのvTunerには対応しているのに、radikoには対応してません。日本で聴くならradikoの方が使いでがあるような気がするんですけどね。それと自社サービスのMusic Unlimitedに対応していないのも最近One Sonyを標榜しているわりには何とも残念な感じがしてなりませんが、ファームアップデートでいずれ対応してくれるのではないかと密かに期待してます。

ダメ押しに、パソコン上の音楽ファイルを同期するアプリがあるのですが、これがフォルダーの作り方が微妙に自分の好みに合わないんですよね。。でも、ネットワーク上にドライブが見えるので、手動でコピーすれば無問題(それにこの仕様なら自分で同期アプリを作ることも可能だから致命的な問題では無いか?)。

それと散々スマホとタブレットのアプリを褒めたあとで何なんですが、やっぱりPCからも操作したいんですよね。その辺り、AIRアプリで作っておけばiOSやAndroidはもちろんのこと、WindowsやMacにも簡単に対応できるのだからメーカーの皆さんはもっと活用を考えるべきだと思うんですけどね?

で、ようやく締めに入るところから本題なのですが(相変わらず前置きが長い)、こういうスマホを軸にした機器連携が今後もっともっと進めばいいのになぁと思うわけです。お風呂が沸いたとか洗濯が終わったとかの単純な通知でもいいし、先のシステムステレオの例のようなUIを拡張するような使い方も便利だし、場合によってはスマホ経由でクラウドのリソースを使うとか、wifiでスマホとつながって協調動作することで以前では考えられなかったようなことが家電(と言うかリソースの限られてる組み込み機器)の世界で出来るようになりそうです。

例えばバルミューダの製品はデザインや機能が素晴らしいので基本的に好きなのですが、UniAutoというスマホとの連携機能を今後実現していくみたいなのでとても楽しみにしてますし(SDKが公開されたら更に面白そうですが)、家電のスマホ連携の流れに先鞭をつけたPanasonicにもすごく期待してます。

常に肌身離さず持っているスマホだからこそ、それをハブ(核)にして家の中の状態の把握や全ての機器をスマホで制御ができる時代が実はついそこまで来ているのかも知れませんね。実際、自分は今後もいろいろな家電を買うと思うのですが、スマホとの連携機能を持っているのかどうか?というのがひとつの重要な判断基準に今後はなるでしょう。

そういうスマホセントリックな生き方の実験を今後してみるのも面白いかも知れません。

2013/08/04

Reboot

大変ご無沙汰しておりました。Facebookの方ではご報告させていただいてたのですが、実は5月に転職をしまして、最初の2ヶ月は新しい職場でこれからやって行けるように、仕事に100%集中すると決めていたんです。

もちろん、土日にだけ個人ワークをするという選択肢もあったのですが、そうすると平日もついつい手を出しちゃって仕事への集中力を欠くだろうと思い自重してました。

7月に少し重い案件が入ってしまい、予定より1ヶ月多くかかってしまいましたが、新しい職場にも慣れ、仕事のペースもだいぶん掴めてきたので、そろそろ活動を再開しようと思います。

まぁ、まずは9/1に久し振りに開催される東京てら子Returnsに向けて何をやろうかなぁ?と漠然と考え始めてますが。。

ということで、各種勉強会への参加も再開しますので皆様よろしくです。

2013/03/23

最近読んだ本

前回(リンク)から半年ほど経ったので、ここらで最近読んだ本に関してまたまとめてみようと思います。今回は結構読み応えのある本が多かったので、数はちょっと少ないかな?

今回は読んだ順に掲載。

■2050年の世界
未来予測はいつの時代も難しいものだが、人口だけはかなり正確に推定できるらしい。それによると、日本のみならず中国も急速に高齢化が進んで2025年頃には経済成長が停滞し、人口配当を受けるインドネシアやインド、アフリカ、中東などが急成長する。当たり前のことだが、若い労働力が豊富な国が人口配当の恩恵を受けてこれから発展するということなんだね。

■WORK SHIFT
グローバル化とITの発展により、働き方が大きく変わるという話し。ただ、当然のことながら全ての職業がこのように働けるわけじゃないし、YahooのようなIT企業でも在宅勤務を禁止するというような話もあるね。ただ、例えばフリーランスの人などが自分の仕事の幅を広げるためには、参考になる話が沢山載ってると思います。

■MAKERS
この本を読めば、3Dプリンターを駆使して誰もが明日からでも製造業を始められるような錯覚に陥るけど、結局それで成功できるのは才能のある人だよね。才能のある人がビジネスをはじめるのに敷居が下がることは歓迎すべきことだけど、自分にもそれが出来るとうっかり勘違いしないように気をつけなくちゃ(笑。あと、クラウドファンディングに関しては、いまのレガシーな製造業のメーカーでも活用する事例がそのうち出てくるんではないだろうか?

■ウェブで政治を動かす
ソーシャルメディアがどこまで民意を反映しているのか?というのには若干の疑問がありつつも、政治活動の多くの部分でうまくITの技術を取り入れたら、かなり政治にかかるお金を減らすことはできそうだから、考えるべきだろうね。

■これだけ!PDCA
PDCAのサイクルがうまく回らない原因は、全てが計画のダメさにあるから。読みやすく分量も少なめなので、リーダー的な業務を行う全ての人にお薦めできる本。と言うか、読んでおいた方が良い。

■良い戦略、悪い戦略
「為せば成る、為さねば成らぬ何事も、成さぬは人の為さぬなりけり」のような精神論的なものは戦略でも何でもないですよ、ということを教えてくれる良書。まずは如何に現状分析をするか?全てはそこから始まる。

■夢をかなえるゾウ2
前作がかなり面白かったので期待してたのだけど、期待が大きすぎたのか平凡だったなぁ。。基本的に前作を読んでないとわからないネタも多いので、まず前作を読むのをお薦めします。何となくシリーズ化を狙っている伏線のようなものも感じたけど、これは前作で終わりで良かったと思うよ。

これからも趣味で読書は続けるつもりだけど、ちょっといろいろ事情があってこれからはあまり時間を取れそうに無いからペースはかなり落ちるだろうなぁ。。

2013/03/17

Hello, Ubuntu Touch

前回のエントリー(リンク)でiOSとAndroidに次ぐ第3極を担うモバイルOSとして、個人的にはUbuntu Touchに期待している旨をお伝えしました。Ubuntu Touchはまだ採用を表明している端末メーカーやキャリアが無く、そういう点ではFirefox OSやTizenからは出遅れている感は否めないですが、逆に完成度の高さはMWCでも評価されてました。

実は友人がNexus7にインストールしたものを私も触らさせていただきましたが、非常にスムーズには動くもののアプリなどの中身はまだほとんどがモックで、商品レベルまでにはまだまだ時間がかかる印象を受けました。

ただ、実機にアプリをインストールすることは可能そうで、Ubuntuからpreview版のSDKもリリースされてますので、今回ちょっとHello worldまで試してみました。

■VirtualBoxにUbuntu12.10をインストール
Macの環境を壊したくなかったので、USBメモリーからUbuntuを起動できるようにいろいろ試してみたのですが、どうしてもできなくて仕方なくVirtualBoxにインストールして実行できるようにしました。インストール方法はここのサイト(リンク)を参考にやりました。

■Ubuntu SDK previewのセットアップ
SDKのセットアップに関しては、公式のサイト(リンク)にやり方が載ってますので、これをそのまま実行すれば良いかと思います。

■サンプルアプリの作成
さていよいよ本題のアプリの作成ですが、これにはQt Creatorという統合開発環境(下図)を使います。ちなみに、Ubuntu SDKがいまはUbuntu用にしか公開されていないので、このような手順を踏んでますが、Qt Creator自体はMac OS X版も存在しますので、Mac用のUbuntu SDKが公開されれば、今回やったようなUbuntu環境のセットアップは不要になるものと思われます。


アプリ作成の手順も公式にあるドキュメント(リンク)を参考にしましたが、基本的にはQtアプリを作るのと相違無いようです。違いはQt用にUbuntu Touchのコンポーネント(Ubuntu.Components)と実機転送のプラグインが用意されているところだけ?なのでしょうかね。

試しに作成したUbuntu Touchアプリのソースコードは以下です。
import QtQuick 2.0
import Ubuntu.Components 0.1
 
MainView {
    objectName: "mainView"
    applicationName: "Hello World"
    id: root
 
    width: units.gu(60)
    height: units.gu(80)
 
    property real margins: units.gu(2)
    property real buttonWidth: units.gu(9)
 
    Label {
       id: title
       ItemStyle.class: "title"
       text: i18n.tr("Hello Ubuntu Touch")
       height: contentHeight + root.margins
       anchors {
           left: parent.left
           right: parent.right
           top: parent.top
           leftMargin: root.margins
           topMargin: root.margins / 2
       }
    }

    MouseArea {
       anchors.fill: parent
       onClicked: {
          Qt.quit();
       }
    }
}
Ubuntu Touchアプリは通常は上記のようなQMLという言語を用いて開発するようなのですが、他のQtアプリと同様にC++を用いて開発することもできるみたいです。QMLは見た通り、ビューとロジックをJavaScriptに似た記法で記述しますが、まだ馴染めなくてもう少し腰を据えていろいろ試す必要がありそうです。

で、実行すると下図のようなウィンドウが表示されました。まぁ、単なるHello worldアプリなので、面白くも何ともないですね。


■所感
歴史と実績のあるQtアプリの開発環境をベースにしているだけあって、特に大きな不具合に遭遇することも無くHello worldまで進めることが出来ました。QMLという言語はちょっと独特で学習コストが気になりますが、Qt自体はMac、Windowsアプリはもちろんのこと、iOSやAndroidアプリも開発できるマルチプラットフォームな開発環境なので、マスターすればもしかしたらいろいろなところで使いでがあるかも知れません。

個人的には、Ubuntu Touchは良くも悪くもUbuntuであるところに魅力を感じております。PC用のOSをモバイルに使うので、確かに消費電力は気になりますがスマートフォンやタブレットのハードウェアスペックもどんどんあがってますので、そのうち問題にならなくなることを期待してます。

あと、昔から外出している時は携帯の形で使えて、家に戻ったらディスプレイにつなげてPC的に使える携帯があればいいなと思っていたのですが、Ubuntu Touchだとまさにそのように使えるんですよね(下図)。


Androidでも確かにテレビなどの大画面なモニターにつないで使うことは可能なのですが、基本Androidなんですよね。PCの形態で使う時は、やはりLinuxの膨大な開発ツールを使いたいじゃないですか?まぁ、Ubuntu for Androidを使えばいいのかも知れませんが、そこは携帯とPCでシームレスに使えるUbuntuにアドバンテージがあるかな?と。

そんなわけで個人的にはUbuntu Touchに期待してますけど、iOSやAndroidの存在を脅かすのはUbuntu Touchでも、ましてやFirefox OSやTizenでも無く、きっとKindle何だろうと自分は思いますけどねw

2013/03/03

Hello, Firefox OS

先週までバルセロナでMWCが開催されてて、今年はiOSとAndroidに次ぐ第3極を担うモバイルOSとして、TizenやFirefox OSに大きく注目が集まりました(Windows Phoneェ...)。

個人的には、iOSやAndroidの牙城を崩すのはかなり厳しいように思い、これまであまり興味が沸かなかったのですが、いろいろニュースになっていることや、Firefoxにプラグインで簡単にFirefox OSのシミュレータをインストールして試せることがわかりましたので、ここのサイトを参考にちょっと試してみました。

アプリケーションを長い時間かけてビルドして作成する従来の方法とは違い、HTML5などのWeb技術でチャカチャカとソースコードを記述してすぐにアプリをデプロイできるこのお手軽さは結構アリでは無いか?と思いました。

そういう意味ではTizenとFirefox OSではHTML5アプリオンリーというFirefox OSの潔さにいまのところは好感を持っております。

Tizenでネイティブアプリをわざわざ作るくらいなら、自分はAndroidでいいですね。Tizenをそこまでして使うメリットを感じません。

ただ、HTML5アプリでは重い処理がおぼつかないというケースも考えられるので、いざとなればNaclでネイティブに処理を逃せるMobile Chrome OSが”もし”あれば、本当なら自分はそっちの方がいいかなぁ?とは思いました。普段のブラウザもChromeを使っているしね。

でもまぁ基本的にアプリロジックで重たい処理はクラウド上のサービスに逃がして何とかするってモデルなんだろうな、とは思います。

ってことで、Firefox OSは想像していたよりも使えそうな印象を受けたのは確かですが、ではAndroidから乗り換えてまで使いたいか?と言われると、そこまででも無いですね。

個人的にAndroidの自由(いい加減)なところとアプリ連携の仕組みはかなり気に入っていますし、何よりbackキーはやはり偉大な発明だったのではないかと思ってます。これがあるからなかなか他のプラットフォームに移るのは今後も難しいような気がしてます。いや、マジで。

それでも、何か他のOSに浮気をするとすれば自分はUbuntu Touchかなぁ?と思います。モバイル用のOSでアプリケーションを真のマルチタスクで動かせるのはいまのところUbuntu Touchだけですよね?だって、中身はUbuntuそのまんまでGUIがTouchデバイス対応にしたもののようなので(詳細をきちんと理解しているわけでは無いので、ウソ書いてるかも?)。

だからきっと電池の消費とかは激しいのでしょうけど、解像度が上がって画面の広くなってきてるタブレット端末なんかは電池容量にも余裕があるし、かなり相性がいいのでは無いかと想像してます。

Tizenはドコモが今年対応端末をリリースすると言ってますし、Firefox OSの端末はauが2014年にリリースを目指しているようなので、Ubuntu TouchやWindows Phone、Blackberryを含め、どのモバイルOSが今後第3極として台頭してくるのか楽しみですね。

2013/01/27

INFOBAR A02インプレッション

普段INFOBAR A01のユーザーなのですが、待望の後継機種であるINFOBAR A02が発表されました。早速、KDDIデザイニングスタジオに行って触ってきましたので、インプレッションを報告します。

■外観
各所でも報じられていますようにINFOBARでこれまで特徴的だった物理ボタンが廃止されてオンスクリーンキーになっており、前面がほぼディスプレイであることと、ベゼルが黒であることから、他のスマートフォンと一見して違いがわかりづらいものとなってしまいました。その為、INFOBAR A01のかわいらしさが無くなった一方で、少しクールな印象の男性向けのデザインとなりました。

これなら、INFOBARじゃなくても良いじゃないかという意見もあるようなのですが、自分は普段、Galaxy Nexusも併用しているので、物理ボタンが無いことにさほど抵抗がないことと、この大きさになると、そのバランスから物理ボタンを配するにしても相応の大きさになるであろうことを想像すると、まぁこれはこれでいいのでは無いかと思います。

だって、A01をただ大きくしただけのデザインだったら、それこそ興ざめじゃないですか?

自分が買うなら色はAOAOですね

■液晶
明るくて非常にキレイだと思いました。今年のひとつのトレンドに5inch FullHDってのがあると思うのですが、(実はこの後にXperia Zも見たのですが)自分の節穴の目には違いがあまり良くわかりませんでした。恐らく、並べて比較すればもう少し違いがわかるのでしょうが。。

個人的にはこのレベルであれば、高解像度であることによるバッテリーの消費電力と端末サイズの増大を天秤にかけても4.7inchのHDパネルも悪くない選択だと思います。

■カメラの画質
これは最近のHTC端末らしく、明るい広角のレンズとか、連射でシャッターを切る機能とか、使い勝手と画質はA01と比較して大きく進化してます。というか、A01のカメラはちょっとひど過ぎでしたよね。。

■音質
実は展示スペースにBeats Audio対応のヘッドホンとともに展示されていることを期待していたのですが、残念ながらそんなことは無かったので、音質は確認できませんでした。

■持ち心地
持った感じ、とても軽く感じました。A01と比較して背面の膨らみが無く、ストレートな形状なので、そこは少し持ちにくさを感じました。個人的には背面は適度な曲面を持ったものが好きなので好みの問題も大きいかと思います。

あと、同じようなサイズのGalaxy Nexusではあまり問題無かったので、ちょっと意外だったこととして、片手操作は少し難しいと感じました。

よくよく見ると、これは端末の角のデザインによるところが大きいと思われます。A02は角こそ丸まっているものの、直角的な形状をしています。Galaxy Nexusは角と底面がゆるやかな曲線を描いてますが、これにより、手のひらのより深くまで端末を握ることができ、親指を隅まで伸ばしやすくなるのです。

Nexus 4がGalaxy Nexusとほぼ同様の形状をしていることから、Googleはこれくらいの端末サイズになるとこの形状が有効だと考えているのでしょう。特許まで取っているのかどうかは知れませんけども :-P

AQUOS PHONE ZETAの特徴的な下部の形状もこのような効果を狙ったものだと思われますが、確信はありません。

Xperia Zを持った時にも同様に(端末サイズがA02より大きいから更に)片手操作は難しいと感じました。確かにスクエアでエッジの効いているデザインの方がクールな印象ですが、ここはデザインを優先するか、使い勝手を優先するか、難しいところだと思います。

そもそもこの大きさで片手操作できる人も限られるので、であれば、デザイン優先でもいいのかも知れません。

■iida UI 2.0
iida UI 2.0は1.0と比べて見た目ほど変わっていないとも、変わっているとも言えます。一番目に付く、スクロール時のゼリーのようなぷにぷにしたエフェクトは触ってて楽しいものですが、高速にスクロールして起動するアプリやコンテンツを探している場合には、確実に視認性が下がります。

まぁ、自分の端末なら、どこに何があるのかはおおよそわかっているはずなので、あまり問題にはならないのかも知れません。

パネルのエディットモードに入った時も、2.0ではゆるやかに画面の輝度が明暗するようなエフェクトになるのですが、これもテーマによってはわかりにくいです。1.0のように明確に画面のモードが変わってわかるようにするか、パネルの色を変えるとか、もうちょっとわかりやすいエフェクトの方が良かったと思います。

でも、これくらいのことは中のひと達でかなり議論していまの形になっているのでしょうから、素人には容易にはわからない何かしら深遠な理由があるのかも知れません。

一方で、サイズの変更などはタップだけで切り替えられるようになっているなど、使い勝手が進化している部分も当然あります。これにより画像のサイズ変更はかなりいい感じにできますが、どんな画像サイズでも思った挙動になるのかは、もうちょっと実験が必要かも知れません。

あと、ピンチ操作でパネルを追加するメニューを表示するのも操作としては、かなり違和感を感じるところなのですが、これはまぁ他にやりようが無かったのかも知れません。1.0との互換性を無視して、ホームキー長押しでも良かったような気もしますが。

今回、端末サイドのファンクションキーを押すと、ListViewと呼ばれる、階層化されてコンテンツに容易にアクセスできるTableView形式のメニューのようなものが用意されました。確かに便利そうではあるものの、個人的にはここの機能はデザインを含め、あまり練られていない印象を受けました。エフェクトもあまり必然性を感じないものです。

iida UI 3.0ではここの機能のブラッシュアップがかなりされるのではないかといまから予想してます。

いろいろ文句を書き並べてますけど、パネルの使い勝手は確実によくなってますし、1.0のユーザーはあまり違和感なく使えて良い仕上がりになっていると思います。特にともだちパネルは便利な機能だと思いました。

ただ、これは展示の仕方の問題なのですが、デモ端末にはある程度ダミーデータの登録をしておいてほしいものですね。twitterとかfacebookのデモ用アカウントも含め。でないと、せっかくの新機能を全部試せないので勿体無いです。

今回、音のデザインを小山田圭吾さんがされたということで、かなり期待していたのですが、音のコンテンツにアクセスするにはau IDの登録が必要とアラートがいちいち出て、非常に鬱陶しかったです。これ実機でもそう何でしょうね。。

あと、メモリーが1GBである点は、短い時間では問題を感じませんでしたが、将来的には不安を残していると思います。A01はバッテリー容量に不安がありましたから、二代続いて不安要素があるのは残念ですね。コストの問題もあるのでしょうが、ユーザーが安心して使えるものを作ってもらいたいです。

でも、個人的には、そんな細かいことを気にする以上にこの新しいINFOBAR A02を気に入ってしまいました。

特にINFOBARは、iida UIの美麗なHome画面からアプリを起動した際に、Androidのくそダサいアプリが表示されて、夢から一気に覚めたような感覚に襲われるのですが、ICSになって確実に改善されているのと、特に今回カレンダーアプリがデザインされたものに置き換わってたのは非常にうれしく思いました。

(おまけ)
同じ日に銀座のソニービルに行って、Xperia Tablet Zを見てきましたが、とにかく薄くて軽くて、かなり良い感じでした。150g軽くなるだけで、こんなにも印象が変わるのかと衝撃を受けたほどです。wifi版が出たら是非購入したいです。


2013/01/05

Home画面のカスタマイズ


ご挨拶が遅れましたが、昨年は大変お世話になりました。当初はいろいろと意気込んではいたものの、夏以降に本業が忙しくなってしまって中途半端に終わってしまっているものを、今年はひとつずつ形にして行きたいと思ってます。

ってことで、本年も当blogをどうぞ宜しくお願い致します。

新春一発目のネタなのですが、私、普段は素のGalaxy NexusとINFOBAR A01を使っているのですが、INFOBARのiida UIがAndroidのHome画面としてはやはり出色の出来だと思っているのですよ。

ただ、偶然ここのページで様々なカスタマイズされたAndroidのカッコイイHome画面が公開されているのを見つけて、正月休みで暇をもてあましていることもあり、幾つか作ってみました。




ご参考までに、今回Home画面のカスタマイズに使ったウィジェットやアイコン、アプリの情報は以下の通りです。

■Homescreenアプリ
Apex Launcher
カスタマイズするベースとなるHomescreenアプリ。これ以外にも、Nova Launcherとか定番のADW.Launcherとかありますので、好きなものを使えばいいと思います。

■ウィジェット
BobClockB3
1枚目の画像のどでかい時計のウィジェット。

Eye In Sky Weather
1枚目、2枚目の画像の天気予報ウィジェット。

Simple Text-Text Icon Creator
テキストから画像データを作成できるウィジェット。2枚目の画像の"WEB" "SNS" "MAIL" "etc."の作成に使用。

- Ultimate custom widget
高度なカスタマイズを行えるウィジェットのベース。端末の様々な情報を取得することができ、それにテキストや画像を適用できる。テーマも豊富に公開されており、究極という名に違わぬカスタマイズの為の定番とも言えるウィジェット。
2枚目と3枚目の画像の時計と日付のテキストに使用(3枚目の画像では更に気温と天気のテキストにも使用している)。

■アイコン
SMPL Blue Theme
1枚目の画像のブルーのアイコン。Apexのテーマに設定できるので、アイコン全体をこれに変更できます。かなりの種類のアプリアイコンをサポートしてますが、対応していないアイコンは当然のことながらデフォルトのものを使うことになります。

RoundGlassBlue icon theme
3枚目の画像の灰色のアイコン。SMPL Blue Themeよりサポートしているアプリアイコンの種類は少ない。

■その他
MultiPicture Live Wallpaper
Homescreenの複数の画面に別々の壁紙を設定できるLive Wallpaper。上記3つの画像をそれぞれ別の画面に割り当てて、いまは3つのHome画面?を切り替えて使う的な使い方をしてます。

- Snapseed
写真や画像を加工するアプリ。上記画像の1枚目と2枚目の壁紙はネットで探してきた無料の壁紙を加工したもの。3枚目の壁紙は自分で撮った写真を加工したものです。適当なフィルターをチョチョイとかますだけでそれっぽくなるのでお薦め。

リンクをたどればわかりますけど、驚くべきことに上記アプリ等は全て無料です。もっと高度なカスタマイズや質の高いアイコンなどをお求めの場合は、有料で公開されているものを活用するのも手だと思いますよ。

私は残念ながらアイコンや壁紙等を自分で作成するセンスや能力が無いので、出来合いのものを使って適当に遊んで作ってみただけですが、本職のデザイナーが気合を入れて作ればかなりイケテルHome画面を作成することも可能だと思われます。

実際、最初に紹介したホームページでもこれどうやって作ってんの?と思うようなものもありますが、大抵はPhotoshop等で作り込んだ背景に透明のボタンを配置しているようなものが多いようです。

まぁ、それはちょっと反則じゃない?と思いますけどね(^_^;

[追記]
英語だけど、ここにもっと詳細にUCCWを使ってカスタマイズする記事が公開されてましたので、もしこれを機会にHome画面のカスタマイズに興味が沸いたら、どうぞ

2012/11/07

【7日目】Tabletかどうかの判定

この記事は、@astronaughts が始められた「Titanium mobile “early” Advent Calendar 2012」向けに書いています。11月1日 ~ 30日まで毎日誰かがTitanium Mobileについての記事を書いていくというイベントです。

 ■Tabletかどうかの判定 
マルチデバイスをターゲットにしたアプリを制作する場合に、対象の端末がタブレットかどうかを判定したい場合があると思います。 Titanium Studioで作成されるテンプレートだと、以下のような素敵コードでタブレットかどうかを判定してくれます。
//considering tablet to have one dimension over 900px - this is imperfect, so you should feel free to decide
//yourself what you consider a tablet form factor for android
var isTablet = osname === 'ipad' || (osname === 'android' && (width > 899 || height > 899));
iOSの場合はこれでも問題無いでしょう。Ti.Platform.osnameが'ipad'を返せば、それは間違い無くタブレットなのでしょうから。

でも、Androidの場合はどうでしょう?上記コードだと縦もしくは横の解像度が900ドット以上だとタブレットと判定するようです。 これそのまま使うと、いまなら多くのAndroid端末がタブレットと判定されてしまうでしょう。ましてやauの冬モデルで発表されたHTC J butterflyなんかは5inchサイズながら1920x1080のフルHD解像度です。Nexus10を別にすれば、その辺のタブレットも真っ青な解像度ですよ。

コメントにもあるようにこの判定方法は完璧とはほど遠く(それにしても"feel free to decide yourself"とは何とお気楽な...)、このような解像度で判定するやり方は進化の早いスマートデバイス業界にはとても通用しそうもありません。 

では、どのようにしてタブレットかどうかを判定すれば良いのでしょうか?タブレットをタブレットとして我々が認識するのはやはりその画面サイズだと思われます。Ti.Platform.DisplayCaps以下にスクリーンサイズを得るメソッドが無くても臆することはありません。自分で計算して求めればいいのです。

HTC J butterflyがスマホで、Nexus7がタブレットとして世の中に認知されているなら、5.0 - 7.0inchの間にタブレットかどうかの判断ポイントがあるようです。以下の例では6.5inchサイズより大きければタブレットと判定するようにしてます。
function isTablet() {
  // xdpi, ydpiが未定義のプラットフォームもあるのでその場合はdpiを使用
  var xdpi = Ti.Platform.displayCaps.xdpi == undefined ? Ti.Platform.displayCaps.dpi : Ti.Platform.displayCaps.xdpi;
  var ydpi = Ti.Platform.displayCaps.ydpi == undefined ? Ti.Platform.displayCaps.dpi : Ti.Platform.displayCaps.ydpi;
  var disp_size = Math.sqrt(
    Math.pow(Ti.Platform.displayCaps.platformWidth/xdpi, 2) +
    Math.pow(Ti.Platform.displayCaps.platformHeight/ydpi, 2)
  );
  return (disp_size > 6.5 ? true : false); // 6.5インチ以上ならタブレット
}
え?いまだとスマホとタブレットの間にphabletっていうジャンルがあるって?
知らんがな...

ってことで、明日は@masapla さんです。よろしくお願いします。

Code strong,

2012/09/21

CloudCore VPS

自分で開発したプライベートな非公開のコードをそろそろsvnとかgitなどのVCSでちゃんと管理したいなぁと思ってました。で、QNAPとかDroboとかのNASでsvnやgitのサーバーとして運用できるものがあるので、それの導入を当初は考えていました。

ところが、ひょんなことからCloudCore VPSという仮想専用サーバーの存在を知り、NASの購入に5-6万も費やすくらいなら、こちらを利用した方が安いかもと思い立ち、今回試しに使ってみることにしました。

もちろんこの場合は、自分でちゃんとデータのバックアップを取ることが前提になりますが、まぁそれなりにちゃんとしたサービスなら簡単にトラブルが起きるとも考えにくいと楽観視してます。いずれバックアップのサービスも開始されそうですし。

運用するOSはとりあえず何か不都合があるまでは、デフォルトのCentOS5.xのままでいいかなと思い、ここを参考に必要最低限の設定を行い、svn+SSLのサーバーとして使用できるところまでに関してはここを参考にセットアップを完了しました。

(CloudCoreはデフォルトではほとんど何もインストールされておらず、それゆえ自分の好みに応じてカスタマイズがやりやすいというのを1つの売りにしているよう?です)

これでノマド生活になっても、どこからでもネットにつながってさえいれば自分のコードへのアクセスやコミットができるようになりました。

後はサーバーサイドの勉強にnode.jsでもセットアップしていろいろ実験してみようかなと思っておりますが、そのような個人的なプライベートサーバー的な使用なら、VPSのスペック(CPU物理1Core/RAM 2G/HDD 10GB)もいまのもので充分以上だと思います。

こういうものが年間1万円程度で利用することができるのだから、まったく良い時代になったものだと思います。これからはこのようなプライベートなサーバーに自分専用の環境を構築し、自作のモバイルアプリでスマホからアクセスして仕事に役立てる、というような使い方をする人が増えるのかも知れませんね。

プライベートサーバーゆえ公開はしませんが、何か面白いものでも出来たらここのblogでまたお知らせしたいと思います。

あ、冒頭のそもそものCloudCore VPSを知ったきっかけですが、自分がちょっと関わっているTitanium Mobileユーザー会用のサーバーが、KDDIの開発者支援制度を通じて無償提供されることになり、その環境がCloudCoreだったというわけです。

そのユーザー会の第1回目の会合が9/24にありますので、もしご興味がございましたら是非ご参加してみてください(atnd)。

ではでは。

2012/09/08

最近読んだ本

去年の年末にオフィスが引越しになり、往復約4時間も通勤にかかるようになってしまいました(涙。まぁ、どうせ寝てるんだろうと思っていたら、もう若く無いせいか、あまり電車では寝られなくなってしまってました・・。

暇だし、時間勿体無いし、積ん読を消化するのにちょうどいいやと思ってたら、意外と読書が面白くなってしまって、最近では月に2−3冊くらい読んでます。

ということで、整理の意味も込めて最近読んだ本をここに列挙してみます。一応、順番は読んだ順番じゃなくて、自分が参考になった/役立った/面白かったと思った順番です。詳しい書評はネタバレになるので1行コメントだけ添えますが、ご興味が湧きましたらご参考に読んでみてください。

特に上から5つめくらいまでは、自分的には結構お薦めです。

■夢をかなえるゾウ
 自己啓発本はこの1冊だけ読めばOK
1分仮眠法
 睡眠の大切さを再認識
ウェブはグループで進化する
 fladdictさんもお薦め
Think Simple
 iMacの名称を考案した広告代理店の方が見たアップルとは?
トレードオフ
 上質か手軽か
FREE
 ご存知フリーミアムの話し
ソーシャルリスク
 炎上しない為にどう対処するのか
世界を歩いて考えよう!(ちきりんさん)
 旅行に行きたくなりました
ゆるく考えよう(ちきりんさん)
 人生がんばらなくてもいいんです
■東電OL殺人事件
 いまだ裁判は係争中
スマホで世界をねらうために知っておきたい3つのこと
 その前に売るアプリを作らないと...
フリーで働く!と決めたら読む本
 別に決めてないけどね
特定の人としかうまく付き合えないのは、結局、あなたの心が冷めているからだ
 まぁ、そう何だけどね
TREASURE MAP 成功への大航海
 買って大後悔?
グーグルで必要なことは、みんなソニーが教えてくれた
 何を学んだのかよくわからなかった
サムスン式仕事の流儀
 サムスンの社員は上下関係が厳しくて大変そうだなぁ

最初は自己啓発やビジネス成功の秘訣みたいな本を選んでましたが、まぁ3冊くらい読めば、大体書いてある内容は同じだな、と気づきました。なので、最近は実用系的な本に手を出し始めてます(笑

2012/09/02

Amazon SIM

いままで、SIMフリーの海外Android端末はb-mobileのfairで運用してました。これは、1GBの通信量を4ヶ月間内に約8000円で使用できるものです。

私の通常のユースケースでは通勤時に電車でちょっとtwitterとかfacebookとかを見る程度なので、これでも充分に余るくらいで運用できていました。

で、Amazon SIMというものが発売になり、こちらの場合は500MBを1ヶ月で約2000円で運用でき、端末が対応していれば更に高速なLTE網が使えるというものです。いま所持している端末はLTEに対応したものは無いのですが、fairで使い続けた場合、1ヶ月で約250MB/2000円となりますので、同じコストでざっと2倍の通信量を使えることになります。

fairでも充分だった私に2倍のデータ通信量も必要無いかとは思いましたが、コストが同程度ということと、将来的なLTE対応端末の入手も見据えて乗り換えることにしました。それで使い始めて、ちょうど1ヶ月経ちましたが、データ通信が思ったよりいってしまい、8月は500MBギリギリでした(汗

通信量が以前よりも大幅に増加した原因のひとつはJelly Beanから導入されたGoogle Nowだと思われます。これがどれくらい使い物になるのかをいま実験してますが、位置情報に基づいて交通機関やら天気予報やらのデータを裏で入手しているので、通信量は確実に増えているでしょう。

しかし、それよりも多大な影響がありそうなのは、Google+とfacebookで、Beautiful Planet EarthとAnimalsというアカウントのフォローを始めたことです。これらのアカウントは美しい地球の風景や動物の写真を頻繁に投稿しますので、これまでのテキスト中心の知人達の投稿よりも確実にデータ量が増えていることは間違いありません。

ただ、画面サイズが大きく、発色の良い有機ELのGalaxy Nexusでこれらの写真を見ると、本当に美して思わず時間を忘れて見入ってしまうほどで、フォローをヤメることはなかなか難しそうです。

後は無頓着にアプリの更新を自動アップデートにしてたので、それで消費される通信も少なくは無かったでしょう。なので、手間はかかりますけど、自動更新はほとんどヤメました。自動更新にしてても、繋がっているネットワークがwifiなら自動ダウンロードするけど、3Gだとダウンロードしないとかまで設定できれば便利だと思うんですけどね。

まぁそんなわけで、キャリアの定額プランよりも気を使って考えながら使う必要は多少ありますけど、その分、値段は3分の1程で運用できますので、使用状況によってはかなりお得かと思います。

ってか、日本のキャリアの通信費用は高過ぎやろ!アホか。

2012/08/15

QuickTiGame2d UI Firstlook

Titanium Mobile用に2D GameエンジンモジュールのQuickTiGame2dってのがあるのですが、自分はゲームとかはちょっと作れません。

でも、UIのアニメーションに使えると面白いと思いたち、作者の方にSpriteのテクスチャーにblobを突っ込めるようにお願いしてみたところ、v.1.3でサポートされましたので早速試してみました。

仕組みは簡単で、通常のTiのViewでUIを作成すると、.toImage()メソッドでViewのイメージのblobを作成できるので、それをSpriteのテクスチャーとして指定します。

で、通常はUIのViewを表示しておいて、UIをアニメーションさせる時だけGameViewを前面に表示させて、アニメーションが終了するとまたUIのViewに切り替えるだけです。

以下がそのサンプルですが、これは2つのViewをフリックで行き来し、行けない方向にフリックするとViewが少し傾くというAndroidではお馴染みの動きです。使っているのはiPodなのですが(笑)


このように簡単に2D効果を使ったUIを作れそうなのですが、いま流行りの折り紙みたいなUIに応用するにはやはり3Dのサポートが必要なので、QuickTiGame3dの登場が待たれます(笑)

とりあえず、短い時間でやっつけで作ったので、コードの整理とサンプルのUIをもう少し追加してからソースコードは公開したいと思います。

Code strong,

2012/07/25

何にお金を払うのか

きっかけは朝に見かけたこの記事だったのです。詳細は記事を読んでいただくとして、要は電子書籍が日本で一向に普及しないのは、メーカーの囲い込み戦略により、Aという端末ではAストアのコンテンツしか読めず、他のストアとの相互利用ができないからだと言うのである。

本当だろうか?もちろん、心理的な妨げの一因であることは間違いないし、誰もが自分の端末で様々なコンテンツを読みたいであろうことは間違い無いけれど、出版社からすればそこに市場があるのならば、様々なストアにコンテンツを提供すれば良いだけの話しである。

記事中にもあるように、マンガまでを書籍に含めれば実は日本は電子書籍大国なのである。結局のところ、日本人はマンガばっかり読んで、その他の書物のニーズがそもそもそんなに多く無いのではないのか?というのが自分の持論です。

囲い込みに関してもう少し言及すると、例えば、家庭用ゲーム機は対応ソフトじゃないと遊べないわけだけど、それが普及の妨げになっているという話はあまり声高には聞かないし、むしろ競争原理が働いて消費者は非常に安くゲーム機を手に入れられるなどのメリットを享受しているように思う。

電子書籍もいまはまだ様々なメーカーに競争してもらった方がメリットは大きいのではないのだろうか?また、記事中にあるiTunesストア待望論も囲い込みという意味では他のストアと同等である。だから、これが決定的な理由になるとは思えない。

(ただ日本人は外圧が無いとなかなか変わることのできない国民性なので、そういう意味で黒船としてのiTunesやアマゾンのKindleに期待するのもよくわかる)

もうひとつ普及を妨げる要因として、電子書籍なのに値段が高いというのがある。電子書籍なんて、紙に比べてコストかかっていないんだから、もっと安くて当然だろうということだ。にも関わらず、電子書籍の値段をあまり下げることが出来ないのは、書店や印刷業者が潰れるからだ。

というようなことが誠しやかに言われるが、そういう都市伝説(と勝手に私は思っている)を恐れすぎず、業界は勇気を持って電子書籍でこれまで本をあまり読まなかった層を開拓できれば、むしろ紙の書籍の売上もあがるんじゃないかというような気がする。

また私たち消費者も、コストにお金を払うというの感覚では無く、もっと価値にお金を払うという風にマインドを少しづつでも変えてった方が良いのではないだろうか?

紙だろうが電子書籍だろうが、そこから得られるもの(= 価値)は基本的には同じものであるはずだ。であるならば、紙も電子書籍も同じ値段でも構わないと私は思う。

(もちろん、現時点で電子書籍から得られるユーザー体験は(私の価値基準でも)紙の書籍に遠く及ばないので、そういう観点からは電子書籍の値段をもう少し下げてもらいたいなーとは私も確かに思うのだが)

そうしないと、際限の無いコスト削減の圧力にメーカーは疲弊してしまうわ、デフレスパイラルもいつまで経っても止まらないわで、景気も良くならないし明るい未来も来ないような気がしてならないんだぜ?w

2012/06/30

パーソナルアシスタントの未来

AppleのWWDC、MicrosoftのWindows Phone Summit、GoogleのGoogle I/Oと、ここのところ立て続けにイベントが開催されて、興味深いニュースが沢山出てきました。

順番は前後して、まずMicrosoftからですが、Windows Phone8でカーネルがWindows 8系に刷新されることが発表されました。Windows Phoneではいままでマルチコアがサポートされてなかった為にハードウェアスペック的にはかなり見劣りしたものとなってましたので、これでようやくiOSやAndroidと戦えるものになりました。

MicrosoftがOSカーネルの基本機能で出遅れるというのも何だか意外な感じもしますが、逆にここはいつでもキャッチアップできるからUXの開発を優先したとも言えます。

ただ、後述しますがAppleやGoogleは既に次のフェーズへと戦いの舞台を移しているので、周回遅れを挽回したとまではまだ言いがたい状況です。

Appleは、今回のWWDCの目玉はRetina Macbook Proで、iOSに関しては控えめな発表のように思いました。これはiPhone5の登場に向けてまだ何か隠し玉があるような気がしてますが、どうでしょうか?

影響の大きそうなところと言えば、Mapを従来のGoogle Mapから独自のものに切り替えたことでしょう。GoogleのAndroidとは競争が熾烈になってきているので、コアな機能を他社に握られたままでいることは好ましくない為、ある意味当然と言えば当然の戦略ですが、まだ地図の完成度が低いので正式版に向けてどう仕上げてくるのか楽しみではあります。

独自のMapを強力な武器に仕上げられなかった場合は、逆に足かせとなる可能性もあり、そういう点では諸刃の剣と言えるでしょう。ただ、GoogleはiOS向けにMapアプリを提供し続けるでしょうから、ユーザーとしては実用的な方を単に使えば良いだけなのかも知れません。

Googleは、Jelly Beanで着実にAndroidの完成度を高めました。特に画面遷移の滑らかさやタッチのレスポンスでこれまで遠くiOSに及びませんでしたので、額面通りに改善されたのであれば、Androidもいよいよ死角が無くなってきたのかも知れません。

もとより、OSの機能としてはAndroidの方が上だと個人的には考えており、ICSでUIのデザインもかなり洗練されたと思ってます。iOSは始めの完成度が高かったことから見栄えはほとんど変わっておらず、そのせいもあってか、情報量の少ないホームスクリーンもいまとなっては何だか古臭く感じるくらいです。

しかしAppleやGoogleはOSの機能よりはスマートフォンの今後のあり方や使われ方、特にパーソナルアシスタントとしての機能向上に開発のフェーズを移しているような気がするのです。

というわけで相変わらず前置きが長いですが、ここからが本題です。

パーソナルアシスタントとしての機能は、AppleがSiriで先鞭をつけた感があるのですが、Androidは従来からある音声検索の機能を改善するという手で来ました。AppleのSiriのように特別なネーミングを付けなかったのは、もしかしたらAndroidという名称自体が既にそのような性格を持ち合わせているからなのかも知れません。

Siriや音声検索はユーザーからの能動的な問いかけに対するものですが、パーソナルアシスタントとしてより重要なのは、Google NowのようなユーザーのTPOに応じてスマートフォンが自律的にユーザーに取って有用な、あるいは利便性の高い情報を提供/提案するような機能でしょう。

しかしこのようなパーソナルアシスタントが有効に機能するには、ユーザーのかなり詳細な行動(スケジュールや位置情報など)やプライベートな情報(交友関係や趣味、趣向など)を情報としてインプットしなければならないので、セキュリティがこれまで以上に重要になります。

極私的な情報がいつネットに流出するかも知れないという不安がある中では、誰も安心して使えないですものね。それにこういうユーザーの行動が広告などに二次利用されることへの嫌悪感をどう払拭できるか?というのも大きな課題だと思われます。

本来、行動ターゲッティング広告というものはユーザーに取ってもメリットのあるものであるはずなのですがね。

また要人におかれましては、自分の位置情報がプライバシーの侵害や犯罪に利用される可能性も否定できないので、こういう技術が単に便利だからと、すぐに世の中で受け入れられて使われるようになるまでは、まだまだ時間がかかるものと思われます。

そういう意味では、ユーザーが機能をコントロールできるon{X}のようなものの方が、始めは受け入れられやすいのかも知れません。ただ、一般ユーザーがJavaScriptでコーディングするというのもハードルが高いし、最終的にはGoogle Nowのような検索履歴等から自動で機械学習するようなシステムじゃないと普及しないでしょう。

パーソナルアシスタントの機能が、ユーザーからの膨大なインプットから、ユーザーがもっとも欲するデータを引き出すものであるとすると、ユーザーからの大量のインプットを処理するには、データを格納する器となるデータセンターやクラウドコンピューティングなどのシステムが欠かせません。

Appleは沢山のアクティブユーザーを抱えていることから、インプットに関しては申し分無いと思われるけど、器を作る能力にはやや不安がある。Microsoftはりっぱな器を用意する力はありそうだけども、如何せんインプットが少なそう?

そういう意味ではこの分野は、いまのところGoogleが一番うまくやれそうな気がします。検索市場を独占していることから、Androidユーザー以外からの膨大な検索クエリーのデータもアルゴリズムの改善に活用できることも有利に働くでしょうし、データマイニングも研究者集団たるGoogleの得意とするところのような気がします。

しかし、AppleのUXデザインの巧みさや、短い時間でキャッチアップしてくるMicrosoftの開発力も侮れないので、実際の人間のように三者三様にそれぞれに性格の違うパーソナルアシスタントとして発展して行けば面白いのではないか?と思います。

例えば、Appleのはクールビューティで的確な回答を示すが扱いが少々気難しいところがあるとか、Googleのはほとんどの場面で完璧な答えを出すけど、稀に重要な情報をうっかり外に漏らしてしまうドジっ娘だったりとか、で、Microsoftのは何でも卒なくこなして実用性では一番なんだけど、なぜだか一般受けが悪かったり?とか。

そんな近未来を妄想する今日この頃です。

2012/05/05

xib2js & TiMockをリリースしました

frogonmobileのサイトにxib2jsの新版とTiMockをリリースしましたので、ご案内すると同時に簡単なQuick startガイドをここに記したいと思います。

基本的に、frogonmobileのサイトで公開している英語版のQuick Start Guideの和訳+αみたいな感じにしたいと思います。

ここのサイトに来ていただいている方ならばxib2jsに関してはもうご存知だと思われますが、前回のエントリーで述べた通り今回はこれのバージョンアップと共にTiMockというTitanium Mobileアプリを併用することで、モックアップを簡単に作成し実機で確認できる環境を構築することができるようになったのが大きな売りとなっております。

ワークフロー的には、下図のようにXcodeでUIのコンポーネントを並べて.xibファイルを作成し、それをxib2jsでJavaScriptに変換した後にTiMockを使って実機やシミュレータ上で確認しながらコンポーネントの位置や大きななどをコードを改変して微調整するという感じになります。


1. XcodeでUIを作成
XcodeでFileメニューからNew Fileを選択し、iOSのUser Interfaceのテンプレートを選択します(ここではEmptyを選択してます)。


後は、コンポーネントを並べてUIを構築していけば良いのですが、ここでの注意点としましては、ファイルの形式を"Interface Builder3.1"を選択しておくことです。それ以外のバージョンではxib2jsが正常にコードを生成できないことを確認してます。


2. xib2jsで.xibファイルをJavaScriptに変換
UIが出来たら、毎度お馴染み.xibファイルをxib2jsにドラッグ&ドロップすると、いつもの通りにJavaScriptのコードが生成されます。


今回のバージョンから生成されるJavaScriptがCommonJSのスタイルに則っていることが確認できると思います。

3. TiMockと連携してUIのカット&トライを行う
さて、ここからが今回の売りであります、TiMockを併用したUIのカット&トライです。まず、TiMockを実機かシミュレータで起動できるようにまずはビルドから始めます。

Githubからコードをダウンロードしたら、Titanium Studioで適当な新規モバイルプロジェクトを作って(Titanium Mobile SDKは2.0を選択する)コードや画像ファイル等をコピーし、ビルドします。

特に難しい部分は無いと思いますが、実機用にビルドする時にはui/ApplicationWindow.jsファイルの31行目のコードのコメントを外してください。
//require("api/Includes");
シミュレータで実行する場合は、そのままビルドして問題ありません。

ビルドが完了しましたら、TiMockを起動してください。TiMockは起動するとBonjourで_timock._tcpサービスをサーチします。xib2jsが起動していれば、xib2jsがこのサービスを提供しますので、TiMockアプリ上に"TiMock Service"というボタンが見えていると思います。


このボタンをタップすると、xib2jsとTiMockの通信が確立されます。xib2js上のSyncボタンが有効になるのと、TiMock上のボタンもConnectedとなったことが確認できると思います。


試しに、この状態でSyncボタンをクリックすると、変換されたJavaScriptのコードがTiMock側に転送されて、UIを実機上で確認できます。


後はxib2js上で微妙なレイアウトの崩れなどを、コード上でコンポーネントの位置やサイズのプロパティ値を調整しながらカット&トライしてUIのモックを仕上げていきます。コードを編集したら、都度Syncボタンをクリックすることで実機上で修正内容が反映され確認できます。

尚、コードの編集に関しては、TiMock上で正常に動作させるには、かなり制約されたものになります。

まず、関数とexportsの定義は変更できません。また、self変数に何らかのUIコンポーネントのインスタンスを格納し、それを返り値として返す形を取る必要があります。
function ApplicationWindow() {             // この行は編集してはダメ
  var self = Ti.UI.createWindow();           // self変数にインスタンス化した
                                                              // UIを格納する
  // ここの中はわりと自由に書ける

  return self;                                          // 必ずselfを返すようにする
}                                                           // この行は編集してはダメ
module.exports = ApplicationWindow; // この行は編集してはダメ
このルールを守れば、逆に関数の中身に関してはわりと自由に書けますが、あくまでも目的はUIのモック作成なので、あまり本格的なアプリケーションロジックをここでコーディングすることはお薦めできません。

とは言え、どんなコードなら動くのかはある程度試行錯誤が必要だと思いますので、いろいろ試してみて自分なりの答えをみつけてください。

また、xib2jsは拡張子が.xib以外のファイルを受け取った場合は、そのファイルをTiMockに転送します。TiMock側は受け取ったファイルをTi.Filesystem.applicationDataDirectoryに保存しますので、コード上でパスを適切に設定することで、画像をUIにはめ込むことが可能です。


ここで指定するパスは、実際のアプリを作成する際にリソースが置かれる位置とは違うものと思われますが、画像がどのような位置・サイズで表示されるのかを確認するには便利に使えるのでは無いかと思います。

また、xib2jsにはファイルをまとめて複数ドラッグ&ドロップしても、同時には1つのファイルしか処理できませんので、お手数でも1つずつドラッグ&ドロップしてください。

4. コードの保存
さて、最後にここまで調整してきたモックのコードを保存します。Saveボタンをクリックするとファイルの保存先を選択するダイアログが表示されますので、Titianium Studio上の適切なプロジェクトのResourceフォルダーを選択してください。


尚、いつもの注意点ですが、保存の際にxib2jsはファイルの存在の有無を確認しませんので誤ってファイルを上書きしないようにお気をつけください。これ、いい加減にちゃんと対応しないといけませんね。。

ここまで来たら、後はTitanium Studioに引き継いでアプリケーションの開発を継続しましょう。

Code Strong,

2012/04/23

xib2js 2.0 preview

久々の更新ですね(^_^;

Titanium Mobile 2.0 ローンチ記念イベント in Tokyo!!が開催されましたので、参加してきました。イベントの詳細レポートはTitanium Newsをどうぞご参照ください。

イベントの中でLTの枠がありましたので、長らく放置してましたxib2jsの新しいバージョンを発表させていただきました。ちなみに、デモがメインだったのでスライドの公開予定は特にありません。

xib2jsで生成するJavascriptは当時のKitchenSinkを参考にしましたので、現在は推奨されていない所謂マルチコンテキストと呼ばれていたスタイルのコードを生成していましたが、今回のバージョンアップで、CommonJSスタイルのコードを生成するように変更しました。

まぁそれだけでは面白くないので、TiShadowを真似て変換したJavascriptを実機やシミュレーターに転送して実行できる機能を組み入れました。

TiShadowでは、HTTPのサーバーと接続するのにIPアドレスをいちいち打ち込む必要がありますが、xib2jsはMac + iOSでの利用を前提にしているので(なぜならXcodeで作成した画面レイアウトをJavascriptに変換するツールなので)、簡単に接続できるようにBonjourを使うようにしました。

後は、画面のレイアウトを作った後に画像データを貼り込むケースを想定して、.xibファイル以外をドロップした時は、端末のアプリケーションデータディレクトリーにファイルを転送して保存する機能も追加しました。

実際のアプリを作成する時は、違うディレクトリーにアセットやリソースを置かれるとは思いますが、実機上で画像の位置やサイズとかを簡単に確認・調整するには便利に使えるかなと思ってます。

正式に公開するまでには、まだじゃっかんコード整理以外にもやることがありますので、もうしばらくご辛抱くださいまし。

Code Strong,

2012/02/24

gumroad考察

gumroadというサービスが注目を集めてますね。自分はちょっとしたトラウマがあって、Paypalのアカウントをまだ作っていないので試していないのですが、これまでとは比較にならないほど簡単に自分のデジタルコンテンツを世界に向けて販売できることが注目を集めている理由みたいです。

と同時に、いやこれは違法コンテンツの温床になるのでは無いか?とか、リンクが漏洩したら誰でも無制限にダウンロードできるのは問題だとか、負の面も報じられてます。

中には、gumroadだけに限った話では無いものもあるし、お手軽さ故にそういうことがより容易に出来てしまうということもあるのでしょうが、個人的には(まだ売れるものなんて何も無いけど)自分のコンテンツを売る販路のひとつとして、こういったサービスがうまく立ち上がってくれればいいなと思っているので、大きな問題が起きないよう、陰ながら応援しています。

で、今回はそういうことを話題にしたいんじゃなくて、私が個人的にgumroadがすごいと思った点を述べたいと思います。

と、その前にオンラインストアと言ってまず最初に思い浮かべるのは何でしょうか?アマゾンですかね、やっぱり。私がgumroadがすごいと思うのは、これのおおよそ対局を行っているのでは無いかという点です。

gumroadのサイトに行けばわかりますが、まず、ここで何を売っているのか?という情報がほとんどありません。それもそのはずで、gumroadは販売するコンテンツを簡単に紹介するページ及びそのリンクと決裁システムの提供しかしてません。

そのリンクがわからなければ、販売しているコンテンツにたどり着くことさえままならないのです。

アマゾンだったら、ユーザーのレビューとかサジェスト機能とか、あの手この手で訪問者にコンテンツを買わせる仕掛けが用意されているのですが、gumroadではそれがいっさい無くて、コンテンツが売れるかどうかは販売者の努力に強く依存しているのです。

このやり方では、ユーザーにリーチできるプレゼンスの無いひとのコンテンツはほとんど売れないでしょう。

ただ、そこをビジネスチャンスとばかりにgumroadで販売しているコンテンツを紹介するなどの周辺サービスがこの短期間で沢山立ち上がってます。gumad.meとか。

ちなみに、gumroadは販売時に売値の5%+30cの手数料を取ることで収益を上げるのですが、決済システムにStripeを使っているらしく、ここの手数料が2.9%+30cです。なので、そのまま単純に引かれるとgumroadの取り分は売値の2.1%と、かなり少ないことがわかります。

また、サービスの性格上、高額なコンテンツがバンバン売れるということも考えにくく、平均の販売単価もかなり低いのでは無いかと思われます。となれば、本来であれば、薄利多売で沢山コンテンツが売れてくれないと、儲けが出ないビジネスモデルであると考えられます。

にも関わらず、売る為の努力をほとんどしないというのは、一体どういうことなのか?で、ここがgumroadの巧妙なところではないかと「勝手に」思っているのですが、実のところそういった販売の為の努力はサーバーの運営コストに跳ね返ってくるわけです。

(えー、いまさらですが、この話はgumroadがAWSとかGAEとかのサービスを使って運営されているという仮定での考察です・・)

沢山のトラフィックを使って、画像やテキストなどで美辞麗句を並べたところで、ユーザーは商品を買ってくれるとは限りません。となると、その時の通信料は全くの無駄になるわけです。

アマゾンはユーザーにより多くの時間をサイトにとどまってもらって購入の機会を増やすのが戦略ですが、gumroadは恐らく、ユーザーがサイトに訪れるのは購入するその瞬間だけがベストで、買うか買わないかもわからないのに長くとどまってトラフィックを消費されるのはたまったものでは無いのでしょう。

だからこの先も販売しているコンテンツの検索とか、そういう類の機能は実装されないんじゃないかと想像してます。

つまり、商社としての機能を極限までシンプルに実現したのがgumroadではないか?ということです。

恐らく今後、gumroadに類似のサービスが沢山出てくるとは思いますが、gumroadという先駆者に対抗する手前、販売手数料はかなり低額な設定にせざるを得ないでしょう。

その際に、このことを理解しないでアマゾンのような機能てんこ盛りのサイトで対向しようとすると、運営コストに苦しんで足元をすくわれることになるやも知れません。まぁ、広告収入とか別の収益源を確保できれば、その限りでは無いのかも知れませんけどね。

もし、gumroadに死角があるとすれば、Stripeを利用すれば類似のサービスを立ち上げることがわりと簡単にできそうで、顧客へのリーチ力があるひとなら、個人で世界を相手に販売サイトを立ち上げる時代が実はすぐそこにやって来ているのかも知れない、ということでしょうか?

2012/02/03

ActionBarにDrop-downナビゲーションを追加する

ActionBarにCalendarやGmailのようなDrop-downナビゲーションを追加しようと思ったんです。

やり方自体は、SpinnerAdapterをActionBar.setListNavigationCallbacks()の引数に指定すれば良いのですが、公式ドキュメントに書いてあるサンプルは選択できる項目が予め決まっているResourceファイルから作るので、コーディングは最小限で済む代わりに動的に選択項目を作りたい場合などはこの方法は使えません。

で、軽くググって見た限りでは世の中にほとんどサンプルが無くて、ちょっと苦労したのでここに簡単にまとめておこうかと思います。そのうちTechBoosterさんにちゃんとした記事が載るような 気がするので、その時はこんないい加減なblogよりもそちらの方をどうかご参照ください(笑

SpinnerAdapterとして実装しないといけないインターフェースは下記
メソッド名概要
int getCount()選択項目の個数を返す
Object getItem(int position)position位置の要素を返す
long getItemId(int position)position位置の要素のIDを返す
int getItemViewType(int position)getView()で作成されるViewのタイプを返す
View getView(int position, View convertView, ViewGroup parent)position位置のViewを返す
int getViewTypeCount()Viewのタイプ数を返す
boolean hasStableIds()アイテムのIDがデータによらず安定しているか?
boolean isEmpty()リストが空か?
void registerDataSetObserver(DataSetObserver observer)データの変更を検出するオブザーバーを設定
void unregisterDataSetObserver(DataSetObserver observer)データの変更を検出するオブザーバーの設定を解除
View getDropDownView(int position, View convertView, ViewGroup parent)drop-downのpopupに表示されるViewを返す

ListViewなんかでAdapterに馴染みがあればほとんどのメソッドに関してはご存知かと思いますが、ここでの肝はgetView()とgetDropDownView()です。

メソッド名からもわかる?ように、getView()がActionBarに選択項目として描画されるViewを返し、getDropDownView()がdrop-downのポップアップに描画されるViewを返す為のメソッドです。

簡単にテキストだけ描画されるようなメニューならメソッド内でTextViewを作って返してやればいいようなものなんですが、getDropDownView()がどうにもうまく行きませんでした。コンパイルまでは問題無いのですが、ランタイム時にエラーが出てアプリが死にます。

LogCatのログを見てみると、どうもLayoutの型変換でエラーが出ているようなのですが、いろいろ試してもうまく行かないので最終的にはlayoutのxmlファイルを定義して、LayoutInflaterでViewを作成するようにしました。

ということで、最終的に以下のようなコードでうまくいったのですが、何か勘違いしているかも知れませんので、識者の方からアドバイスをいただけると幸いです。

SampleActivity.java
public class SampleActivity extends Activity implements OnNavigationListener {
  private ArrayList menuList = new ArrayList();
  private LayoutInflater mInflater;
  private ActionBar mActionBar;

  @Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    mInflater = (LayoutInflater)mContext.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
    mActionBar = getActionBar();
    mActionBar.setNavigationMode(ActionBar.NAVIGATION_MODE_LIST);
    mActionBar.setListNavigationCallbacks(new mSpinnerAdapter(), this);
 
    // drop-downメニューのデータを自由に作成
    // ここではコード上の文字列を設定してますが
    // 例えば、IntentのBundleで受け取ったデータ
    // をもとに作成してもいいでしょう
    menuList.add("One");
    menuList.add("Two");
    menuList.add("Three");
  }

  private class mSpinnerAdapter implements SpinnerAdapter {

    @Override
    public int getCount() {
      return menuList.size();
    }

    @Override
    public Object getItem(int position) {
      return menuList.get(position);
    }

    @Override
    public long getItemId(int position) {
      // とりあえずpositionをIDとして返す
      return position;
    }

    @Override
    public int getItemViewType(int position) {
      // 何を設定すればよいのかわからないのでとりあえず
      // IGNORE_ITEM_VIEW_TYPEを返す
      return IGNORE_ITEM_VIEW_TYPE;
    }

    @Override
    public View getView(int position, View convertView, ViewGroup parent) {   
      if (convertView == null) {
        // getView()はこれでうまく行く
        convertView = new TextView(mContext);
        LayoutParams params = new LayoutParams(LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT);
        convertView.setLayoutParams(params);
      }
      ((TextView) convertView).setText(menuList.get(position));
      return convertView;   
    }

    @Override
    public int getViewTypeCount() {
      return 1;
    }

    @Override
    public boolean hasStableIds() {
      return false;
    }

    @Override
    public boolean isEmpty() {
      return false;
    }

    @Override
    public void registerDataSetObserver(DataSetObserver observer) {
      // TODO Auto-generated method stub   
    }

    @Override
    public void unregisterDataSetObserver(DataSetObserver observer) {
      // TODO Auto-generated method stub
    }

    @Override
    public View getDropDownView(int position, View convertView, ViewGroup parent) {
      if (convertView == null) {
        // getDropDownView()はうまくいかないので
        // LayoutInflaterでViewを作成
        convertView = mInflater.inflate(R.layout.dropdown_menu, parent, false);    
      }
      ((TextView) convertView.findViewById(R.id.dropdown_menu_item)).setText(menuList.get(position));
      return convertView;
    } 
  }

  @Override
  public boolean onNavigationItemSelected(int itemPosition, long itemId) {
    // itemPositionの選択に応じた処理
    return true;
  }
}

dropdown_menu.xml
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical" >

 <TextView
        android:id="@+id/dropdown_menu_item"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />
</LinearLayout>

2012/01/29

Android Usability Seminar 2012

日経BP主催のAndroid Usability Seminar 2012というのに参加してきました。ホームページの開催のお知らせから内容を察した限りでは、Androidアプリを作成する際のUX的な内容かと思い参加したのですが、内容的にはちょっと自分の思ってた方向とは違ったものの、かなり面白かったので、簡単に紹介したいと思います。

1. アップルから学ぶユーザビリティ 山中俊治氏
Suicaの自動改札機のデザインを担当。Suicaに限らず電子マネーなど、いまでは常識となっているタッチするという行為を人々にどうデザインの力で認知させるのかという課題を解決する為に、ユーザビリティテストを行い検証を行った。

ユーザビリティテストを行う上で重要なこと
  • 開発の初期段階で行う
  • 少ない人数でも構わない(回数を多く回すことの方が重要)
  • 周到に計画する(ユーザーを疲れさせない)
  •  クライアントを巻き込む
とにかくいままでに無いものを作るのだから、考えすぎても意味が無い。こうあるべきというイメージは人それぞれに違う。そして、何よりもユーザーは予想もしないことを平気でする。なので、沢山の施策を試してみて、結果(事実)を皆でシェアすることが重要。

この仕事が山中さんにとってユーザビリティテストの重要性を認識する転機になったようで、その後の大根おろしの仕事につながったそうです。この話もかなり面白かったのですが発表されてた資料なしに伝えるのは難しいかな?

膨大な大根おろしの刃の試作がなかなか圧巻でした。ポイントは、機械的な規則正しさを廃して、刃の並びにある程度のランダム性を持たせること。そうすると、大根を持ち替えたりおろす方向を変えたりしなくても、最後まで気持よくおろせるものができるそうです。

で、話は変わって山中さんから見たアップル製品の凄さは、「無垢」な塊としてのハードと赤子にもわかるインターフェース。特にハードに関しては、デザインの為に日本メーカーではまず考えられないような高コストなNC切削加工による量産技術を立ち上げたことがスゴイと。

そしてNext Stepとして、次の時代のデザインは生きものらしいデザインが来るのではないか?人間は生きているかどうかに敏感であるので、生命を感じられるもの、そしてコマンドによらないコミュニケーション、など。

2. 最新事例に学ぶユーザーインターフェースの研究 増井俊之氏
増井さんはいまの携帯電話でもはやデファクトとなっている予測漢字変換をソニーPCL時代に考案して、その後アップルに行って、かの有名なフリック入力の漢字変換システムの開発に携わったそうです。

その為か、話しのほとんどが漢字変換システムに関する話だったのですが、面白かったは、いまのスマホの漢字変換システムに全く納得されていないようで、曰く、何故にガラケーと同じようなキー配列や入力システムを採用しているのか?せっかくタッチインターフェースになったのに、新しいチャレンジが何も無いとのこと。

iPhoneの漢字入力に関しても全くお気に召さないご様子(あれ、開発に携わったはずでは?)で、あれを有難がって使っているのは、スティーブ・ジョブスに絶対騙されてるだろうと(笑)。

後は連文節変換なんてものは全く無用の長物で、かな漢字変換というのは本当は簡単で誰でも作れ、自身がRubyで600行程度で書いたかな漢字変換システム(名前失念)とか、Android用に作ったSlimeの紹介とかとか。

そして、増井さんの考えるユーザーI/F開発のタブー
  • 素人の意見を聞く
  • 多くの意見を聞く
  • 古いものを無意味に模倣
逆に正しいユーザーI/Fデザインの方法
  • 有能な人が少人数で作る
  • シンプル
  • 捨てる勇気
  • ユニバーサルのデザイン
  • 素人の感想は聞くが意見は採用しない
まぁ、言わんとするところは何となくわかるような気もします・・(^_^;

で、増井さんによると、GUIに関しては20年前から全く進化していない。スクロールバーなんてあれが使いやすいとは思わないけど、あれ以上のものを何で誰も思いつかないのか?

ということで、ご自身の活動としてGoldfishというAndroidの実世界GUIのフレームワークの開発をされています。どういうものかは、ここの blogで紹介されている記事をご参照いただくのがわかりやすいかと思います。

3. iCloudとSiriに見るサービスデザイン 奥出直人氏
本題であるはずのSiriに関しては、冒頭にかの有名なナレッジナビゲーターのビデオを数秒紹介して終わり(えーっ?)。

で、後はDesign Thinking(デザイン思考)というメソッドでのプロダクトやサービスデザインの話でした。カルボナーラを誰でも美味しく作れるシステムとか、医療関係のサービス開発の話で、個々の内容は興味深かったのですが、デザイン思考とはなんぞや?というところに関しては、頭が悪いのかあまり理解できませんでした(汗。

基本的な考え方として、どういう課題を解決したいのか?どういう付加価値を提供するのか?(Human Value)というところから入るのですが、そのフェーズでの重要な点は、現場が何に困っているのかを理解すること。

だけど、それを現場に行って実際に見させてもらうことが、そもそも非常に難しいこと何だと(これは多分医療用サービスを携わったことから来る経験談だと思われる)。なので、ユーザーとの信頼関係を築くことがとても重要。

そして、ここでも作ったものをユーザーに実際に使ってもらい、そのフィードバックから何度も作り直したという話を聞きました。

後は、その課題を解決する手段のTechnologyとして、いまのクラウド環境やスマートフォン、タブレット端末などは非常に強力で安価なツールになってきているので、プロトタイプがすぐに作れるからチャレンジしてみたらどうか?

そして、それがある程度成功したら、最終的にはそれをどうBusiness(どこで儲けるのか)に結びつけるのかを考えなければならないので、サービスのデザインが重要(だからデザイン思考なの?)。

そのヒントとして、大量のデータをクラウドのパワーで処理した結果を端末のI/Fの面白さにどう結びつけるのかを考えてみればいいのでは無いか?とのことでした。

とまぁ、思ってた内容とは多少違ったけども、話としては面白くて得るものが多かったセミナーでした。