読者です 読者をやめる 読者になる 読者になる

iPhone 向けアプリを設計する際に考えること / 実践! OSSプロジェクトのソースコードビュワーアプリ

前提

CodeLibrary というAndroid のアプリが意外と需要がありそうだとわかった

空き時間にスマフォでソースコードが読める『CodeLibrary』をリリースしました! - hamheiの日記
http://d.hatena.ne.jp/hamhei/20111224/1324734053

iOS 版が欲しい」という声が多数
http://b.hatena.ne.jp/entry/d.hatena.ne.jp/hamhei/20111224/1324734053

なのでこれのiPhone 版を考えるとどうなるのか、というのに興味があって書き出してみた。

5W1H / プロダクトデザイン

そのアプリがあることによって、誰の何がどうなるのかというものを事前に把握したいのでそこから想像する。

シナリオ 1
  1. ソフトウェアエンジニア が
  2. iPhone を使っ て
  3. 移動中の電車内など で
  4. オープンソースプロジェクトのコードリーディングを し
  5. あらたなソフトウェア開発技法の知見を得 て
  6. 世界を変える人を増や し
  7. 世界を変える
シナリオ 2
  1. ソフトウェア開発上の作業環境 に
  2. スマートフォンという道具を利用する選択肢を加える と
  3. イノベーションが起きる

※生む機械やばい(http://blog.livedoor.jp/dankogai/archives/51206767.html

価格

free

脱力レビューに日和って用もないのに有料にしない
(※「マイナス票の効力よりも、プラス票の効力が大きい」というゲーム構造 http://ulog.cc/a/fromdusktildawn/12153)

広告

なし

目標ダウンロード/ユーザー数を決めておき、それを越えたら検討しはじめる

リリース計画

最小の目標が実現された時点で最速リリース

勝てる方法はただ1つ。とにかく早くローンチして、スタープレーヤーより速く動くことだ。ミニ四駆の肉抜きのイメージで、スピードで勝てるまで機能は削らないといけない。

(http://chibicode.tumblr.com/post/7797166283)

初期バージョンをリリースし、ユーザーが増えそうならその後の展開を考える。
自分も使い、自分が気にくわないところはその都度アップデート(特権)
自分もユーザーもいなくなったらそのまま放置

アプリの広告(いわゆるローンチやリリースの広告)は考慮しない

男なら黙ってリリース

(https://twitter.com/#!/hamhei/status/151945490383122432)

最小の目標

提供できる最小の価値を考える

前提: github 上のプロジェクトのソースコードを見るだけのツールなら既にある

「できること」から機能、仕様を制定する

1. 任意のOSSプロジェクトのソースコードが読める
  • github 上にあればなんでも
  • git リポジトリならなんでも
  • URL があればなんでも など。パターンがある
2. 読むソースコードスマートフォン画面に最適化する
  • 1行の長さの最適化
  • タッチパネルで読みやすい配置の考案
3. コメント、注釈機能
4. 静的コード解析、タグジャンプ、履歴管理などの閲覧補助機能が使える(※http://b.hatena.ne.jp/hiboma/20111225#bookmark-73354929)
  • Exuberant Ctags like
  • GNU GLOBAL like(主要LL 対応してないけど)
0. +アルファ


1. までやると既存アプリと並ぶ。
1. までやってあとは日本語UI という価値を+ して日本市場へリリースするというのもアリ(個人的にはつまらない)
2. 3. はやると世界市場でも価値がでそう?(キラーアプリ)
4. だとawesome
0. が妄想inbox

なので初期バージョンの理想は 2. になった時点です

iPad 版は?

直立、片手操作を主としているので初期バージョンはiPhone 版のみを対象とします。

開発の期間

よーいドンからアップルサーバへのアップロードdone までを予測。
1〜2ヶ月ぐらいを予測。

開発の費用

高度な専門知識を必要としなさそうなので
開発期間から推測し、そろばんをはじく。

自分でやるのでゼロ。

運用の費用

今回はサーバ側を用意しないのでゼロ
といいたいところだが、間接的にはアップルのデベロッパープログラムの年会費を払います。

iTunes App Store で配布するか?

まずそもそもネイティブアプリじゃなくて、ウェブアプリ(ウェブサイト)にした方がデバイスも限定されず便利なのでは? という疑問点がある。
しかし今はもう事情が違って、ネイティブか? ウェブか? と二元的に判断するのではなく混合したハイブリッドな設計のアプリというのを前提に"実現したい機能" で考えていくことをお薦めします。

まず考えるのは、iTunes App Store で配布するか/しないか? です。極論で言えばアプリをインストールし、起動する過程が第一のユーザーインターフェイスとも言えます。

"このアプリを" なぜ iTunes App Store で配布するか
  • ユーザーはApp Store アプリでこのアプリをダウンロードし、インストールできる
  • 国際化展開がしやすい
"このアプリを" なぜ iTunes App Store で配布しないか
  • ユーザーはリンクをタップするだけで、アプリを使うことができる

「ウェブアプリ(ウェブサイト)にした方がAndroid に移植簡単」「審査がないのでアップデートが早い」等が入っていないのは何故? と思うでしょうが、ウェブアプリにした上でiTunes App Store ストアに出品という手段もあるので、「iTunes App Store で配布するか/しないか?」 ではとりあえず考慮しません。

Web API でデータを操作する必要があるか

次に考えるのは Web API でデータを操作する必要があるかと、それを自前で用意する必要があるのか? です。
一例としてよくあるのはログイン機能。ログイン情報を検証する為にWeb API は必要、twitterFacebook コネクトなどを利用すれば自前で用意はしなくていい。
あと単に「ウェブサイトの内容を画面に表示」というだけでもWeb API でデータをダウンロードしている、と考えることにします。

将来的に静的コード解析をするのなら、解析を実行する同じ場所にソースコードもあった方がいいですが、今の時点で考えるのは上記ぐらいです。他のユーザーとデータを共有する手段もまだ考えません。

ウェブアプリとして構成して、サーバ上に対象のソースコードを置くのなら別ですが、この時点では自前でWeb API を用意する必要はなさそうです。URL からダウンロード、例えばgithub ならソースコードをZIPでくれAPI などがあります。この点、HBFav というアプリAPI を自前で用意する必要がなさそうですが実際は既存のWeb API で不十分な部分を補う為に自前のAPI をブリッジに構成しているようです。

パフォーマンス面で考えておくこと

パフォーマンス面で言えば例えばテキストファイルを画面に表示するとに関して、この時点でもネイティブAPI利用した方が早い/遅いという比較は考えてもしょうがないでしょう。設計時やレビュー時に問題が発生した時点で考えます。

事情が違うのはインタラクティブな即時フィードバックが要求されるビデオゲームや、ネットワークインフラが万全ではない国向けへ配布したい時。この場合は画面遷移、操作ごとに通信を要求されるようなウェブアプリベースではキツイでしょう(もちろんPhonegGap のようなパッケージウェブアプリという形体もありえます)。
このあたりの実行速度と開発速度の問題への取り組みとして近年DeNAGREE はngCore, Unity などの仕組みに注力しているようです。

Q: Titanium Mobile, PhoneGap は使った方がいいのでしょうか? CoffeeScriptは?

A: 勝手にしろや


個人的にはよっぽど大規模なレガシーコード化しなければObjective-C ベースのがよく。ソースコードの理解しやすさ(多くの場合Cocoa系のが冗長*1 )、XcodeIDE の補助、リファクタリングデバッグのしやすさ、ドキュメント・ナレッジベースの量などから、Objective-C でコードを書きたいとは思っていますが。今からObjective-C 覚えてもツブシがきかねーじゃねーか的な意見の人もいます。あとそもそも大規模なレガシーコード化はどの世界でも糞です。

このアプリで言えば、趣味で考えている段階でなくなると人が死ぬシステムでもないのでコードベースが肥大化したり設計上の問題が出た時点で全部捨てます。

コード設計、ビジネスロジック的な話

なにを実装すればいいのか。

  • ソースコードを読み込む / CodeReader
    • gitweb やgithub 上のURL からUIWebView で表示
    • ダウンロードしたファイルから UIView で表示
  • GitHub API 操作のクライアント(必要に応じて)

重要なのはプロトタイプをビルドし続けれる状況で開発してゆくこと。なのでソースコードダウンロード処理を書くより先に、既にダウンロード済みのソースコードを画面に表示する処理から書く。この辺はつくっているうちに2転3転し、そして予測期間はアテにはならないでしょう。
なぜ「プロトタイプをビルドし続けれる状況で開発してゆく」のかというと、開発中は特にユーザーインターフェイス変更の優先度が高く、ユーザーインターフェイスの改装工事につられてデータ構造や操作の大改造を行う & もしくは見ないフリをし醜いコードの道をつき進んでゆく、というパターンがよくありうるので(顧客の為のアプリならなおさらだけど、自分自身で考えているものでも使ってみないとわからない感覚が多々ある)
それを吸収する為に「成果物はトップダウンで、ソースコードボトムアップで用意(実装ではないことに注意)」という挟み撃ち方式の方針をとった方がうまくいくという感覚があるからです。
そしてGHUnitKIF によるテストファーストをおすすめします(建前ではなく)。

Q: あれ? UI設計はしなくていいの? 画面遷移やワイヤーフレームは?

A: (このアプリでは)いらない

「どこの画面に何のボタンがあるのか」から決めてはいけません。
何ができるのか から = UI はどうした方が良いという手順で考えてゆきます。
「プロトタイプをビルドし続けれる状況で開発してゆく」方法をとっている恩恵はここででてきます。

まとめ

ここでは一例として、スマートフォン向けアプリケーションの設計する際の思考過程を解きました。
個人により大分流儀は異るところがあると思いますが、参考になればと思います。

蛇足: 俺はこう思う

ここまで書いておいてなんだけど、今のところ開発に取り組むかは未定だし
そもそも俺はアップルとデベロッパー契約していない……(そしてAndroid ユーザー)

この話題でおすすめの書籍

Amazon.co.jpiPhoneアプリ設計の極意 ―思わずタップしたくなるアプリのデザイン: Josh Clark, 深津 貴之(監訳), 武舎 広幸, 武舎 るみ: 本
http://www.amazon.co.jp/dp/product-description/4873115027

インタラクションデザイン

まああるだろうな、とは思ってたけど上記で書いてるような方法論はインタラクションデザインという用語で呼ばれているものに近いというのに気付いた。

別に俺が経験をもとにインタラクションデザインと同じ考えに辿りついたわけじゃなく、この考えに影響をうけた人の考えやマッシュアップしたものとかで伝達されてきたんだろうけど。
逆にいうと学習して、インタラクションデザインの語彙で書けばその方面の専門家からのツッコミを期待できるかなと思いました。

*1:冗長な方が理解しずらい人もいます