アプリの構想

導入

いったんWebアプリを思いついたら、コーディングやデザインを始める前に計画を立てるべきです。大半の皆さんにとっては驚くほど明らかですが、完全に新規のアプリを作るのか、既存のアプリを目的変更するのかは、言い過ぎることのないポイントです。この記事ではアプリケーションを計画し、実装の準備する時に心に留めておく主要な概念に触れます。

これは簡潔な、一般目的の作業手順で、始めようとする人に役立つよう設計されたものです; つまり経験のある企業開発者の場合、おそらくopen Web app開発に適用できる作業手順や習慣があるでしょうし、そちらがよいです。

趣意書

まず始めに、アプリが意図する機能性と、ターゲット顧客をできるだけ正確に書き出し、ターゲット顧客がそのアプリを使うコンテキスト/状況を考えます。単純なLocation Finder(居場所を見つける)アプリ向けに、次のように、2つのリストを書き出しました:

機能性

• 端末の位置情報をできるだけ正確に取得する
• その位置情報をGoogleマップ上にプロットする

ユーザグループ

• open Web app と Firefox OS 開発について学習しようとする開発者で、おそらくオフィスか電車の中にいる
• どこにいるのか知ろうとする人は誰でも、特に屋外や、家の遠くで

アプリをできるだけ単純に作ります; つまり1つのこと —またはそれによく関係した少しのこと— を良くするのに集中します。達成すべき色々なユースケースがたくさんある場合、別々のアプリに分割するのが望まれることもあります。アプリが異なるプラットフォームで異なる体験を必要とすることもあり、なのでデスクトップ用とモバイル用(やタブレットやTVなど) にリストを分けないといけないこともあります。

次に、ユーザに親切なアプリ概要を、人がダウンロードして試したくなるように書いてみます。1つの文に要約できる場合、アイデアはアプリに良くはまっています! Location Finderアプリ用にはこう書きました:

Locatin Finderは位置情報を使って、あなたはどこにいるのかわかり、またGoogle Maps APIを使って周辺の地図をプロットします。

純粋なエンドユーザ向けには、通常テクノロジー名は入れないようにするのも良く; つまりこんな具合になるでしょう:

Location Finderであなたはどこにいるのかわかり、また周辺の地図をプロットします。

ただこのアプリは大きく開発者教育を狙っているため、この情報は有益だと判断しました。

アプリ概要を作り出す

いったんアプリの意図とターゲット顧客を決めたら、紙のスケッチから始めるのが常に良い案です—アプリがどのようなものか、ユーザがアプリを使うワークフローについて、ラフな画面をいろいろ書いてみます。上記の機能性リストで必要となる場合は、デスクトップや、モバイル、タブレット、TVなど、たぶん別々のスケッチを書きたくなるでしょう。

どの場合も、画面資産や、機能や、各段階で要る諸々のメモを入れます、なぜならこれはいつ設計や開発の段階に入るかを教えてくれて、何かを忘れるのにくくなるのを保証します。"Location Finder"では機能性はとても単純なので、たった一つのスケッチを書くことにしました:

より複雑なアプリでは、主なビュー表示に複数の画面スケッチを入れたり、次にユーザがアプリを使うにつれて、異なるビューで異なる作業手順を表現したくなるかもしれません。

あらゆるプログラムが (変換されて) Open Web Appsとして動作しますか?

単にあらゆるページや、プログラムや、サイトがopen Web appとして動作します、ただし既に上に載せた助言に従っている限り; 何にもましてシンプルさを保って下さい。アプリが特に複雑な場合 (例えばワープロや大規模 e-コマースプラットフォーム)、それは全コンテキストを1アプリで動作すべきではないでしょう、ゆえに別の体験を作ることを考慮します、モバイルやタブレット端末とか。例えば、eBayのデスクトップサイトには広告や、色々な検索機構や、その他機能を完全なホストしています。それに比べてモバイル版サイトでは大半の機能や広告が隠されて、最も人気の機能をインターフェイスの上に示し、必要となるキーボードの相互作用の量を最小化しています。

Google Docs はもう一つ考えられる面白い例です。デスクトップサイトはフル機能のワードプロセッサでたくさんのコントロールが使用できますが、モバイルサイトで使うと悪夢です。ゆえにモバイル版は単に文書を読む事ができて、簡単なインターフェイスを備えています。

この段階で、どうやってこれから色々なバージョンを提供するかを考えます。大半の状況では、メディアクエリを使用して、異なるブラウザ向けにプロジェクトのレイアウトや機能性を最適化する事ができます。しかしながら、重くて古い、企業のデスクトップwebサイトのモバイルアプリ版を作る仕事を与えられた場合(またはデスクトップとモバイルの体験が根本的に異なりすぎるのが分かった場合)、モバイル・タブレットで別々のサイトやアプリを作る方がよいかもしれないのを頭に入れていおいて下さい。

必要なテクノロジーについて考える

上記の "趣意書" の段階とこの段階を一緒にしてしまう人があります。しかし、間違いなく、機能性・レイアウトをテクノロジーと完全に分けて考える方が、しばしばより良くなるでしょう。機能性については、純粋に最初の事例でユーザにとって何が最良なのかを考えるべきで、テクノロジーは最新で、最高の、ピカピカなおもちゃであるため、これをプロジェクトに押し込めるべきではありません。最も簡潔なアプローチが最良です。

もっと詳細な考慮についてはWebアプリを開発する節にて議論していますが、一般にはアプリの主な機能性・要求事項や、それを実装するのに最も良いであろうテクノロジーについて考えるべきです。疑問になるであろう例は、こうしたものを含みます:

• オフラインのストレージは必要ですか? アプリに永続的なデータが必要な場合、通常はサーバサイドの言語とデータベースが必要となるでしょう。オフラインデータ・端末にインストールされたデータを使い続けたい場合、クライアント側のストレージ機構、例えばIndexedDB やローカルストレージにデータを貯めてもよいです。
• メディアの再生や、操作をしたいでしょうか? たぶん <canvas>, <video>や、 <audio>といったHTML5の機能が必要でしょう。
• 端末や、その環境の情報を得たいですか? Battery Status API(電池状態)やProximity API(近接センサ)やDevice Orientation API(端末の向き等)といった、多数の利用可能な端末APIのどれかが必要となるでしょう。

テスト計画

通常は明らかに考えておくべきだが、しばしば軽視されるもう一つの事は、テストする事です。なるべく早期になるべく頻繁にテストすべきです。なぜなら、基本的な失敗を早期に発見する事は、多くの開発が完了したもっと後と比べると、多くの時間とお金を節約できるからです。一般的なテスト計画は下記の通りです:

• いったんアプリの機能声明と、対象顧客を書き出したら、それを多くの同僚・友人・家族と共有します。事の起こりから良いアイデアに聞こえますか、あるいは馬鹿げたように聞こえますか? 微調整や、適切に範囲設定をし直す事が必要でしょうか?
• 同様に、フィードバックを求めてラフスケッチを共有します。明らかに欠けている物はないですか? その他に、体験に加える意味のあるものはないでしょうか?
• 次に、人がキーとなる機能性とインタラクションをテストできる、機能プロトタイプを作成する事が良い考えでしょう。開発チーム外の実ユーザがインタラクションをテストする選択を得て、彼らがうまくやっていけるかを見てみます。セットアップをテストするプロのユーザを雇えなくても、問題ありません—友人や家族の選択はほぽ同じくらい良くて、あなたは正しい疑問やテストを管理できます。
• アプリ開発作業を一通り終えた後、ユーザテストの手順を出来るだけ多く繰り返すのが賢明です。今や実際のアプリの作業をしていて、主なサポートターゲットから始めて広げていき、なるべく幅広い種類のブラウザや端末でテストします。それぞれのブラウザや端末で何が受け入れられるかを考えて、通常の使用法だけをテストする事のないようにします—ストレス下においてアプリがどういった動作をするか、悪意のあるデータや本当に古いブラウザといったエッジケースも見て行きます。
• プロジェクトの終わり近くに、細かく邪悪なバグ (これは全然予想していない時に、いつも首を噛んでくるやつです) を取り除く、厳しいQA(品質保証)テストの期間を取ります。

結論: 考慮するポイント

希望としてはこの記事がopen Web app作成に成功する前に考慮が必要な点をほぼ与えているでしょう。下記の一覧は要約です。

アプリの目的は何?

タスクリストや、アプリのアイデアや、ターゲットユーザの種類を作り、目標声明を書きます: アプリの目的と最も重要なユーザを可能な限り1つの文で定義します、例えば: 決して衝動買いしない人のためのウィッシュリスト作成ツール。

主なユースケースに注力する

目標声明のリストに全てのタスクを入れるのことはできない可能性があります。でもOKです、なぜなら素晴らしいアプリ (特にモバイル向け) は一つのことをうまく行います。アプリがしようとする事が多すぎる場合、機能性を複数アプリに分割することを考えます。しかし、アプリが価値を届けるのに多数の機能を必要とする場合、デスクトップPC 専用にアプリ配信する考慮を覚えておいて下さい。

人がどのようにアプリを使うだろうか?

ここまでで、主なユースケースや、ターゲットユーザや、キーとなる機能を決め終えました。ほかに考えるべき主なシナリオはアプリが使われるユーザ環境でしょう。例えば、赤ちゃんを日中のお世話に連れている若いママは、素敵なお散歩ノートのアプリを使うかもしれません (マルチタスクや、停止して後で続けるができる)。別のユーザは家でアームチェアに座って誰にも邪魔されず、次のノートパソコン購入を計画するかもしれません。

少ない重要機能に集中する

もう一度タスクリストを見ましょう。リストを目標宣言でふるいにかけます。目標宣言とタスクがそぐわない場合、アプリから除外します。コアタスクを機能として記述して自身に問いかけます。この機能は本質的か?とか、あるいはあってもいいが、ターゲットユーザが決められたタスクを完了するのには不要か?とか。自分に正直になります。短い機能リストを完了したら、正しい軌道に乗っています。思い出してください、最良のアプリは一つの事を上手に行います。アプリの失敗はしばしば、少なすぎるのではなく、多すぎる機能が理由となっています。

しかしながら、目標到達のために単に大きな機能を提供しないといけない場合、デスクトップ Web アプリ 用を最初のアプリとして作り、次にユーザが単にデスクトップから離れた時にいる機能や役割のある、補完するモバイルアプリを提供する事を考えます。

アプリを作り出す

いったん少しのキーとなるインタラクションを決めたら、これらのステップを画面に移転します。ユーザフロー、つまりユーザが画面から別の画面に移って完了させるタスクをスケッチできます。アプリの機能性を考えて、最も重要なインタラクションが最も目立つ場所に対応するようにユーザインターフェイス要素を配置します。デスクトップ対タブレット・モバイルで画面がどのように見えるかを考えます。

必要なテクノロジー

機能性リストを見て、その要求を築くにはどんなテクノロジーを使うだろうかということについて、いくつかメモします。

テスト計画

プロジェクト計画の中で合理的なテスト計画を立てます、これは後の実装段階で、予想外に高くつく驚きの可能性を減らすためです。

参考情報

• Open Web apps
• Web アプリを開発する