モバイルアプリケーションの進化





スマートフォンは、アプリケーションを起動するためのアイコンで満たされた画面のアイデアであり、「クラシック」デスクトップデスクトップを使用する義務があります。 しかし、近年のスマートフォンの長い道のりにもかかわらず、特定の独立したアプリケーションへのリンクであるアイコンの概念は変更されていません。 たぶん、このアプローチを再考する時ですか?



モバイルデバイス(ラップトップ、スマートフォン、タブレット、ウェアラブルガジェット)を使用したコンテンツの消費方法は、大きく変化しています。 別のアプリケーションのアイデアはますます重要になりつつありますが、代わりに、コンテンツを含む通知を備えたコンテンツを公開するためのツールとしてのアプリケーションの概念が最前線にもたらされます。 ほとんどの場合、これにより、アプリケーションの設計と開発者の製品戦略へのアプローチが変更されます。



デスクトップがアイコンで詰まっていない



そのような大きな声明には説明が必要です。 したがって、使用するために開く必要がある個々のアプリケーションにリンクする画面上のアイコンの束のアイデアは、ますます無意味になりつつあります。 代わりに、バックグラウンドで実行され、コンテンツを中央アグリゲーターに配信するアプリケーションの原則に移るのがより論理的です。 これは、最新の通知センター(パネル)またはGoogle Nowに類似したものか、まったく異なるものです。



主な設計スキームは、カードの使用です。 この場合、アプリケーションのコンテンツと対話する単純な視覚的な方法ではありません。 カードをアプリケーションからのコンテンツのコンテナと呼びます。 一見したところ、その差はそれほど大きくありませんが、実際にはそうではありません。 これを理解するために、2つのポイントについて説明します。



1) 最終製品ではなく、システムの開発 。 現在、ほとんどの開発者は最終的なソリューションを作成していません。 以前は支配的であったこのアプローチは、今日急速に消滅しています。 画面サイズと解像度のあらゆる種類の組み合わせを備えたモバイルデバイスの巨大なエコシステムでは、非常に多くの異なるガジェットで表示できるように、コンテンツを小さなコンポーネントに分解する必要があります。 たとえば、FacebookはWebサイトでもアプリケーションでもありません。 これは、モジュールオブジェクト(人、写真、ビデオ、コメント、ブランドなど)のシステム全体であり、ニュースフィードやさまざまなデバイスの画面に表示するためのさまざまなスキームに従って組み立てられます。 Facebookは、動的なページやアプリケーション画面のセットではなく、オブジェクトとそれらの関係のシステムの典型的な例です。



2) 2つの主要なモバイルOSの通知システムの最近の変更 。 Android KitKatとiOS 8のリリースにより、通知は単なる他の場所へのポインター送信ではなくなりました。 現在、通知は特定のアプリケーションを起動します。つまり、最終製品である宛先に転送します。



しかし、それだけではありません。 Androidでは、通知で特定のアクションを直接実行できます。 このユーザーがアプリケーションにスローされることもありますが、多くの場合、その起動は必要ありません。







Androidの次のバージョンでは、開発者は通知を個別のカードに分割することでさらに前進しました。







ご覧のとおり、通知ポインターから、さまざまなアクションを実行できるコンテンツを含むコンテナー(カード)にすばやく移動しました。



次のステップは明らかです。すべての必要な機能を完全に実装するカードの数が増え、各カード内のワークプロセスの独立性(分離)が明らかになります。 ソーシャルネットワークへのコメントの投稿、オンラインストアでの購入、飛行機の出発時刻の確認、友人への興味深いニュースの送信、カレンダーへのリマインダーの追加、レストランでのテーブルの予約、トレーニングの結果へのコメント、請求書の支払いなど



サービスとしてのアプリケーション



この概念では、コンテンツとアクションを含む小さなモジュールにアプリケーションを分解する必要があります。 このようなモジュールは、アプリケーション自体のコンテナに関連付けられておらず、任意のデバイスに表示できます。 コンテンツが変更されると、モジュールは単純に再構築、中央集約、またはクライアントデバイスにプッシュされます。



コンテンツを再フォーマットして、状況に合わせて最適化したり、特定のユーザーアクションを促進したりできます。 たとえば、友人からテキストメッセージが送られてきましたが、その瞬間に私は運転しているので、スマートフォンや時計は自分でメッセージを読むだけです。 その後、私は仮想アシスタントへの回答を中傷し、テキストに変換して友人に送信します。



アプリケーションと対話するための主要なインターフェイスのみがアプリケーションではない可能性が非常に高くなります。 最初に述べたように、アプリケーションは何よりもまず出版ツールになります。 そのため、アプリケーションと対話する主な方法は、通知レイヤー、またはアプリケーション自体の起動を必要としないカードの集約されたストリームです。



コンテンツを送受信する方法として通知が完全に支配されている状況では、「昔ながらの」アプリケーション全体を実行する必要はありません。 同じFacebookを見てみましょう。OSレベルで通知カードを使用してメッセージを送受信できるのに、なぜモジュールからアセンブルされたアプリケーションを起動するのでしょうか。 Windows 8にはデスクトップ画面とタイル画面の両方があるため、数年のうちにアプリケーションアイコンのある画面がUIの複製バージョンに変わる可能性があります。



「カードシステム」のコンセプトデザイン



おそらく、これらすべての議論は現実からあまりにも離婚しているように思われるでしょう。 議論されていることを誰かが理解するのが難しいことを排除しませんので、私のポイントを説明しましょう。



トピック、コンテンツ、日付、またはその他の基準でパーソナライズおよびソートされた垂直方向のカードのストリームを想像してください。







カードは、あなたが興味を持っている、またはあなたが許可を与えたソースから来ることができます。 数量は決して制限されません。 一部は、ステロイドのGoogle Now、または最新の通知センターのように見えます。 しかし同時に、カードは何かを報告するだけでなく、カード内であらゆる種類のアクションを実行する機会を提供します。 言って、ソーシャルネットワークにメッセージを書いてください。たとえば、共有、保存など。 そして、ウェブサイトやアプリケーションを開かずに、テープで大丈夫です。



カードを水平方向に反転できるように、別の自由度を追加します。 たとえば、1つのソースから異なるコンテンツを表示します。







当然、これはすべてのタイプのガジェットに実装できます。







続けましょう。 下の図のように、階層システムを実装する、つまり親カードとドーターカードを作成することが可能です。 ちなみに、似たようなものが既にTwitterに存在しています。







同様の試みは、中国のBaiduおよびWeChatアプリケーションでも見られます。小さなアプリケーションがメインアプリケーション内にパッケージ化されており、特定のユーザーアクションでのみ表示されます。 たとえば、バイドゥマップでは、ホテルを検索して部屋を予約できます。



しかし、これは最も興味深いものとはほど遠い。 さらに重要なことは、カードを埋め込む(子カードを親カードに)ことは、子カードのコンテンツを使用するためにアプリケーションをまったくインストールする必要がないことも意味します。 親カードに対応するアプリケーションがデバイス上にあれば十分です。 繰り返しになりますが、このアイデアはすでにTwitterで実装されており、彼らのカードはストライプ支払いをサポートしています。 この概念がどこにでも実装され、開発者が新しい強力な配布チャネルを受け取ると想像してください。



別のアイデアがあります:カードが他のものやデバイスから来た場合はどうなりますか? たとえば、コーヒーマシンはこの購入の支払いを提供していますか? または、ホテルはWi-Fiアクセスまたは追加サービスの請求書を送信しますか?



Webサイトの分岐メカニズムには、別の考慮事項があります。 ある主要なニュースリソースが、そのコンテンツと共にカードを他の多くのサイトに配布しているとしましょう(もちろん無料ではありません)。 では、なぜこのリソースに独自のWebサイトがあるのですか?



「1つの連続したテレビ」があり、起動する必要のある「クラシック」アプリケーションの使用を停止するとは言いたくありません。 いずれにせよ、ソフトウェアとのそのような相互作用を必要とするタスクは保持されます。 たとえば、コンテンツを組み合わせて、さまざまな特定のタスクまたは複雑なタスクを実行します。



大衆への機械学習



ユーザーが一方のカードに注意を払い、もう一方のカードを無視すると、システムは学習し、ユーザーが興味を持つ可能性のあるコンテンツを正確に表示しようとします。 さらに、ニュースリソースやソーシャルネットワークだけでなく、あらゆる種類のアプリケーションがコンテンツのソースになることもあります。 その結果、ユーザーの注意を引くための競争の再考につながる可能性があります。 人々の利益のための戦いは、同じカテゴリーの製品ではなく、同じ仕事をする製品を始めるでしょう。 このための前提条件は今日守ることができます。スマートフォンの通知センターでは、あらゆる種類の通知があなたの注意を奪い合うと言うこともできます。



開発者は、製品が突然完全に予想外の競合他社を見つけたという事実に出くわす可能性があります。 実際、Twitterは他のソーシャルネットワークと競合するのではなく、アプリオリにユーザーが多くの時間を割く必要のないエンターテイメントアプリケーションと競合するとします。 つまり、Twitterはニュースリソースやカジュアルゲームと競合できます。



3つの重要な質問



私が説明した将来の多くの前提条件にもかかわらず、議題には多くの質問があります。 私自身は、3つを選びましたが、まだ答えられません。



1)カードモデルは次のレベルで実装されますか?

•アプリケーション(Google Nowの進化など)

•通知(最新の通知センターの進化として)

•またはオペレーティングシステム?



2)カードは1つの共通ストリームとして表示されますか、それとも複数ストリームですか? 友達に関連するカードのストリーム、ニュースストリーム、ワークストリームなどを考えてみましょう。



3)このモデルはユニバーサル形式で実装されますか?それとも、オペレーティングシステムの開発者からの独自のバージョンに遭遇しますか? または、 WildcardCitiaによって今日開発されたものに似た、オープンクロスプラットフォームシステム(インターネットなど)でさえもですか?



新しいサービスと製品



エンドユーザーは、「カードシステム」への移行から多くのメリットを得ることができます。 このアプローチは、私たちが消費する情報量の壊滅的な成長の問題を解決します。 ただし、このためには、カード自体の数を制御し、それらのソート方法を学習し、テープを管理する必要があります。 しかし、「クラシック」アプリケーションに焦点を当てた現代のエコシステムのフレームワーク内よりも、情報フローを制御する方がはるかに簡単で簡単です。



個々のカードをリンクすると、重要な情報と、それを操作するために必要なアクションのみに集中できます。 あらゆる種類のセクション、リンク、バナーなどに気を取られることなく



開発者は、製品に関する情報を広めるのがはるかに簡単になります。 アプリケーションストアでの広告に頼る代わりに、ドーターカードの形式を含むユーザーフィードに関連コンテンツを含むカードを埋め込むことができます。 さらに、アプリケーションとその機能に関する情報の両方を含めることができます。



5つの主要な調査結果



1) ウェブの未来はカードにあり、開発者は最終製品ではなくシステムを設計する必要があります。 さらに、カードとシステムのアイデアはすでに実践されています。



2)レスポンシブデザインは良いことですが、先に進む必要があります。 コンテンツは、信じられないほどの数のデバイスで、等しく多様な状況で正しく表示されるはずです。 これには、新しい設計原則への移行が必要になります。



3)通知と通知内で実行されるアクションを慎重に検討することは、ソフトウェア開発においてますます重要になります。 ユーザーとの対話のこちら側には、さらに注意を払う必要があります。



4)製品を統合できる場所について考えます。 時間が経つにつれて、これは製品戦略の重要な部分になり、APIとWebhookの数が増え、ZapierやIFTTTなどのサービスの役割も増えます。 統合することで、自分ではほとんどできなかったことができるようになります。 特に、より多くのユーザーにアクセスできるようになります。



5)デバイスのクラスを1つだけに制限するのではなく、スマートフォン、タブレット、ウェアラブルガジェットの分野における最新のトレンドに常に遅れないようにしてください。 結局のところ、新しいトレンドはあなたが待たなかったところから来ることができます。



カードの概念はYotaPhoneで発展していると言わなければなりません。 同時に、ほとんどすべてのウェアラブルデバイスが死んでしまうという主な欠点がありません。ウェアラブルデバイスでは、カードを受け取ったときにモバイルデバイスで基本的なユーザーケースを終わらせる必要があるためです。 基本的なシナリオのウェアラブルデバイスでは、より多くの時間が必要であり(また、不必要な通知で不必要なプッシュによって注意がそらされます)、時間を節約するユーザータスクを解決しません。



これについて、Luke Wroblewskiが次のように述べています: http ://www.lukew.com/ff/entry.asp?1943



All Articles