やってみましょう。 これを行うには、どの原則が開発されているかを理解する必要があります。数年前に使用した洞窟技術と、今日使用する「未来の技術」にどのように変わったかを慎重に検討してください。
長い例
数年前、私が1つのサイトにフォトギャラリーの管理パネルを構築していたとき、いくつかの入力の形で投稿する通常のアプローチはあまり良くないことに気付きました。特に、未知の比較的大量の写真を事前にアップロードする必要があることを考慮してください。 解決策は、5つのフィールドと「追加」リンクを作成して、別の追加フィールドを動的に作成することでした。 同僚の助けを借りて、「さらに5つ追加」というリンクを添付し、「未来のテクノロジー」の準備が整いました。
そして、彼女はしばらくの間本当に良かったです。その後、別のプロジェクトで、私は写真をアーカイブにアップロードしていました。 新しい方法には利点がありました-多くのファイルを選択する必要がなく、欠点があります-ユーザーは画像を事前にパックする必要があり（管理パネルでは通常、フロントエンドでは受け入れられません）、画像の順序を制御する方法はありません。
時間が経ち、1年ほど前に、次の新しいプロジェクトでいつものように同じタスクが再び発生しました。 違いは、第一に、今回はフォームが「人々向け」であり、第二に、フォームあたりの写真の最大数が少なかったことです（写真は実際に成長し、過去に重量が増えました）。 最終的に実装されたソリューションは次のようなものでした。1つのフィールドは、iframeを介してすぐに送信されると、処理結果（URLおよび統計）が元のフォームの非表示フィールドにプッシュされ、ミニチュアとして表示されます。 ここには多くの利点がありますが、私たちにとっての主なものは、画像とフォームを個別にダウンロードする機能（画像の読み込み中にフォームを追加することで待ち時間を短縮できる）と、アプリケーションサーバーをバイパスして別のサーバーに画像をアップロードする機能です。 このすべてをウィジェットでラップすることにより、このプロジェクトで画像のアップロードを処理する必要から自分自身を救いました。 このため、この方法は私たちにとって今年の「未来のテクノロジー」になりました。
ご想像のとおり、1年後、古いソリューションは私たちを満足させるのをやめ、アップグレードすることにしました。 まず、可能なすべてのブラウザ（IEを除くすべて）で、ファイルアップロードフィールドが複数になりました。 第二に、可能であればどこでも（IEとOperaを除く）、iframeの代わりにクロスドメインファイルのダウンロードでAJAX 2を使用し始めましたが、File APIを使用して複数のファイルを別々のファイルに分割し、ダウンロードを加速してサーバーを簡素化しました一部（ピンチを並列化する必要はなく、エラーを1つの結果に集約する必要もありません）。 さて、それは十分クールに聞こえます、さようなら。
インターフェース
画像のダウンロードに関する短編では、インターフェイスと技術の両方の個々の手順のさまざまな理由と利点について言及しました。 次に、インターフェイスに関係のないものをすべて削除し、すべてがどこに行くのかを考えてみましょう。
インターフェイスを他のすべてのものから分離するには、それが何であるかを明確に理解する必要があります。 インターフェイスとは何ですか？ さて、これはウォームアップするにはあまりにも複雑な質問です。別の簡単な質問をしてみましょう。 いつインターフェースに遭遇しますか？ 一般的な答えは次のようになります：ある種のシステム（プログラム、サービス）を扱っており、それが私たちのために何かをしたいとき。 それは合理的に聞こえます、私たちは少し修正してこれから踊ります：システムは、原則として、私たちと他の人々の間（または私たちと物理的現実の間）の仲介者です。したがって、それは言葉遣いから破棄されるべきです、すなわち。 何かが欲しいとき、私たちはインターフェースに直面します。 このように：
インターフェースは、人と彼が望むものとの間の障害です。
この結論と最後のいくつかのフレーズが曖昧で過度に一般化されていないように、写真をアップロードする例に戻りましょう。 このインターフェイスにアクセスするときに、人は何を望みますか？ 写真をサイトにアップロードしますか？ そうではなく、より正確には、これは部分的にしか真実ではありません。実際、彼は他の人に自分が見た/見たものを見せたいと思っています。 2番目の定式化はより一般的であり、利点があります。「サイト」と「写真」の両方が元のタスクに含まれていない追加のエンティティであることが明らかになります。インターフェースの面で勝つでしょう。
定義から、理想的なインターフェースは、ユーザーの要望が追加のステップなしですぐに満たされるインターフェースであることがすぐにわかります。 そして、これらの非常に追加のステップとエンティティは、タスク自体には含まれていませんが、インターフェースで使用されるため、インターフェースの複雑さが増します。
学習レッスン
さて、このすべての知恵を得て、私たちはそれを写真付きの物語に適用しようとします。 明確にするために、各ケースのインターフェイスの複雑さのすべての要素を書き留めます。
0.前に来たもの。 手順-個別のフィールドで各画像のファイルを選択します。十分なフィールドがない場合は、すべてを繰り返す必要があります。 追加のエンティティは、一度に写真の最大数です。
1.フィールドを動的に追加します。 手順-個別のフィールドで各画像を選択します。十分なフィールドがない場合は、1つの特別なリンクを使用して追加します。 追加のエンティティは、フィールドを追加するためのリンクです。
2.アーカイブでダウンロードします。 手順-目的の画像でアーカイブを作成し、フィールドでアーカイブファイルを選択します。 追加のエンティティはアーカイブです。
3. iframe。 手順-1つのフィールドで写真ファイルを1つずつ選択します。
4.複数+ファイルAPI + AJAX 2.手順-アップロードフィールドで必要なすべての写真ファイルを選択します。
ステップと追加の概念を繰り返すたびに次第に少なくなっていくのがわかります。最後のオプションは一般的に優れているようです。1つの余分なエンティティではなく、1つのステップだけです！
どんなに。 ユーザーが望むものの最も一般的な言い回しを思い出してみましょう：「自分が見ているものを他の人に見せたい」とすぐに、上記のすべてのオプションに共通する追加のステップとエンティティに気付きます。 手順-写真を撮影し、コンピューターに転送し、ブラウザーを起動し、サイトにアクセスし、承認し、フォームに記入し、フォームを送信します。 エンティティ-ファイルのダウンロード、ファイル、写真、カメラ、コンピューター、ブラウザー、ウェブサイト、フォーム、インターネット。
くそー、成長する余地がある！ そして、将来の私たちの技術は、以前のすべての技術と同じ成果物になり、可能な限り多くの改善が見られるようです。 これらの追加手順と概念をどのように排除できるかを見てみましょう。
ステップを削除する効果的な方法の1つは、ユーザーが何かについて考える必要がない場合、それを自動化することです。そうすれば、それはインターフェース要素ではなくなります。
ファイルのダウンロードは自動同期に置き換えることができます。これは、Dropboxと一部のGoogleドキュメントがすでに行っていることです。 Dropboxの例は、1つの非常に一般的な問題を解決し、これに基づいてビジネス全体を構築するという点で正当化されています。
ファイルをコンピューターに転送し、ブラウザーを起動すると、モバイルアプリケーションに置き換わります。 電話のDropboxクライアントは、これらの手順を効果的に排除し、サイトを操作するためのその他のモバイルアプリケーションも排除します。 ブラウザを起動する必要のないChromeOSオペレーティングシステム全体もあります（さらに、もちろん、アプリケーションのインストールと作業環境の同期が大幅に簡素化されます）。
ファイルやインターネットなどの基本概念を排除することもできます。 ファイルの概念は、ユーザーが画像、ビデオ、音楽、書籍、または連絡先を扱い、ファイルを扱うのではなく、iOSで完全に隠されています。 インターネットが消滅しつつあります（ユーザーの懸念リスト、したがってインターフェースから）。それがいつでもどこでも、Amazon Kindle 3Gの無料のユビキタス接続である場合、この意味では、無料のトラフィックだけでなく、インターフェースの質の向上です。
より身近に
インターフェースの多数の残りの断片を誰かが何らかの形で克服していることがわかります。 問題は、インターフェースを改善するために何が思いつくかということでした。 再び写真の例に戻りましょう。
同期のパスをたどることができます。 特定のフォルダーに保存されているコンピューター上のすべての写真は、サイトに表示できます（たとえば、「並べ替えられていない」モードですべてを公開し、ユーザーが都合の良いときにすべてを整理できるようにするなど、公開するための特別な手順を追加できます）。 モバイルアプリケーションの場合は、同期がさらに便利になります。キャプチャされたすべての写真をサイトに表示できます。
これはすべて大規模なリソースには適しています（私がFlickrの場合、クライアントをカメラに押し込む方法について真剣に考えます）が、小さなサイトの作成者は何をすべきでしょうか？ 答えは、外部サービスと統合することです。 ユーザーから写真を取得する必要がある場合、これはファイルのダウンロードを整理する必要があることを意味しません。実際、これはユーザーが何かをアップロードする必要があることを意味しません（たとえば、ユーザーが既にそれを行っているため）。 これらの写真をどこで撮れるかを考える必要があります。 そして、そのような場所はそれほど多くありません。Gravatarからアバターを、ソーシャルネットワークやFlickrなどのサービスからさまざまな写真を、Dropboxから任意のファイルを取得できます。
サードパーティのサービスを使用すると、大きな利点が得られます。
-ある時点で、このサイト機能の実装とサポートを自分で単純に放棄することができます。
-統合するサービスに表示されるすべての設備を自動的に受け取ります（ユーザーに提供します）。 DropboxはPS 3のクライアントをリリースします-スクリーンショットをそこからダウンロードできます。Flickrはカメラの悪名高いクライアントになります-あなたは再び勝者です。
このようなアウトソーシングにより、より優れたインターフェースを取得できるだけでなく、サービスの正確な機能に集中できます。 たとえば、コラージュを作成するためのオンラインエディターの作成を計画している場合、従来の方法を使用して、ユーザーの登録/承認、画像のアップロード、コメントシステム（ユーザーなしの場合）およびアプリケーション自体-特別にシャープ化されたフォトエディターが必要です。 これらすべてを自分で行う代わりに、ソーシャルネットワークを承認に使用し、FlickとDropboxを写真のソースとして使用し、Disqusをコメントシステムとして使用できます。 さらに、サードパーティサービス（主にソーシャルネットワーク）も、公開のための優れたメディアとして機能するため、アプリケーションの口コミ広告としても機能します。 あなたがやるべきことは、あなたが実際にやろうとしていることだけです-オンラインのコラージュ編集者（そしてもちろん、それをすべてまとめて）。
コア以外のすべての機能の開発とサポートに時間を費やさなければ、エッセンスである作成、この場合はコラージュエディターが優れている可能性があります。 アプリケーションは簡単なことを1つ実行します。 また、Unixの類推を完了するには、アプリケーションを他のユーザーと連携するように教えます-APIを提供します。
あなたは何をしているのかを決定します-別の（おそらく良い）サービスまたは将来のネットワークの基盤にある別の石。