Firebaseを使用したプログレッシブWebアプリの設計について – デザイナー VS 開発者

当記事はクリエイティブ・コモンズ・ライセンス(Creative Commons license / CC license)に基づいて翻訳・編集しています。

Mustafa (以下M):  PWA(プログレッシブウェブアプリ)のデザイナーと開発者にとってのチャレンジは、Googleがサイトをアプリ的に動作させることは素晴らしいことだと押し続けているってことだよね。というのも、アプリには、特にモバイルデバイスでアクセスできるAPIが多くあるから。

も、実際はそれを実現するのはとても難しいことで、参入障壁そのものが実に高い。その上で、Firebaseはその問題を軽減する、つまり参入障壁をかなり低くするような方法を取り入れていると思うんだけど、どのようにFirebaseはそれを可能にしているの?

 

David East (以下D ): そうだね。アプリ的に動作するものみたいな話があったけど、そこで考えることは、人々はアプリにどのようなものを求めているんだろうってこと。通常、1秒あたり60フレームくらいで構成されているものを見ているわけで、何もかもがとにかく瞬時に表示されているように感じる。つまり、タップすれば、すぐに表示され、データがその場でアップデートされるような感じだ。

Firebaseは、何かひとつアップデートすると、すぐさま別のデバイスでもアップデートされるようなデータベースになっている。クラウドといったあらゆるものに適用できて、ひとつ変更が加えられたら、すぐに連携している全てのデバイスが同期されるということ。こういうことが、アプリ的な動作の要素であり、情報が即座に変更され、自分のデータが手持ちのディバイス全てからアクセス可能なユビキタス状態にあるということだと思う。

そして、アプリのように、オフラインであってもそのユビキタス状態が保たれることが求められるということになる。

 

M: そうだね。

 

D: アプリをインストールすれば、ほとんどの部分にアクセスできる状態になる。Firebaseは同じことをしていて、何か変更を加えたら、その情報が実際そのデバイスに保存される。オフラインになると、例えば、僕はカメラのPWAの構築をしたことがあるんだけど、僕が構築できるオンラインで使用する場合と同じことを、オフラインでもできるようなものとはどういうもので、その中に「即時性」を見つけ出そうと必死だったんだ。

もしオンライン上だけで作業をするなら、ノートアプリみたいにその場で変更が同期されるのがわかる。でも、カメラアプリの場合、ウェブ・ユーザーメディア・API、そして小型カメラを搭載させ、写真をとる、そこからその写真を保存して、写真フィードができる。何がいいかというと、飛行機に乗っていても写真を撮ることができて、それをそのデバイスに保存しておけば、ネットワークに接続すると同期が始まる。

つまり、自分の所有するデータベースやサーバーをインストールするとか、IndexededDBみたいなものを設定する必要もないということなんだ。単に、Firebaseライブラリー的なものを使って、そこからそれぞれの機能を手に入れて、それを作動させていくみたいな感じで、自分のアプリを構築していくことだけに集中しているんだ。オフライン作業はどのように動作するかとか、データ連携はどのように動作するかといったことは気にせずに、むしろ自分の作業そのものに集中するようにしているよ。

 

M: 使用するという点において、アレックス・ラッセルとも話してきたことのひとつが、どのツールを採用するかは、ディベロッパーもしくはデザイナーのやりやすさ次第だということなんだ。

例えば、WordPressはインストールさえすれば、はい完成という感じだよね。

 

D: 5分間インストールしたら、はい。

 

M: そうなんだ。PHPやWordPressを忌み嫌うのがトレンドみたいな感じになっているとは言え、そういったものも、100種類を超えるいろいろなライブラリをインストールすることなしに、やりたい仕事を円滑にスタートさせ進めるためにデザインされたものだよね。そういう点では非常に上手くいっている。

で、Firebaseはおそらく同じような考え方のもとにあると思うんだけど、セットアップがとてもシンプルになっている。

 

D: ちょうど2週間前にFirebaseに参画して4年目を迎えたところなんだけど、それこそ入社1週目ですら、ちょうどFirebase Hostingの立ち上げをしようとしていた頃なんだけど、その時の僕の仕事はただひたすらユーザー研究のミーティングに時間を費やしていたんだ。その頃は、この会社に入って、リアルタイムデータベースやJavaScriptライブラリを構築すると思っていたから、「よし、腕まくりして1日中コードを書きまくるぞ」といった感じだった。

だから、ほとんどの時間をユーザー研究に費やしていることに衝撃を受けたね。ただただ座って二重ガラス式の窓越しに眺めている感じ。もちろん文字通りそうしていたわけではないけど、そう感じたよ。そこで、ユーザーを見てみると、彼らはセットアップそのものに苦戦しているんだ。

で、自分は次にそのユーザーが何をすればいいのか正確にわかっている。そのボタンをクリックするんだ!頼むからそのボタンをクリックしてくれ!ってね。こっちを見て「どうすればいいの?」っていう表情を見せてきても、こっちとしては「何もできないんだ」となるだけ。使い方が理解できていないユーザーを見ることで、自分自身の反省点を知ることができる。だからこそ、かなり初期の段階から、僕たちはユーザー研究にフォーカスしていたんだ。もし5分以内に立ち上げて作動させることができないのなら、それは機能していないということ。

ユーザーを見るということの最も重要なポイントは、自分たちが成し遂げようとしているものの全体図を描くことにある。だから、まず初めに、JavaScriptライブラリを採用しようということになった。そして現在のリアルタイムで連携するアプリになった。つまり何のセットアップも必要なくなったんだ。

次に、証明に関する部分を発展させた。GoogleアカウントやEメールパスワードのような様々なタイプのプロバイダーのユーザー情報でログインできるようにしたいということを可能にしたんだ。そして、サーバーを起動させたり、JavaScriptライブラリに余計な情報を追加したりしたくないという場合でも、このアプリがあればそれが解消される。ホスティングに関しても、どれだけの速度でインターネット上に存在していないサイトをCDN上でSSL化し、高速動作をデフォルトのようにできるか、というのと同じことなんだ。そういったこと全てが僕たちの血として常に流れていて、一番の指針のようなものなっている。導入の障壁を低くして、5分以内にスタートさせ、起動できるということ。

 

M: じゃあ、例えば僕が、僕みたいにウェブデザイナーで、技術的に詳しいことがわからない人間が、独自ドメインでサイトを立ち上げたいとなって…。そうだな「davidtheshop.com」とかなんとかみたいなドメインを購入するとしたら、どれくらいの時間でウェブのURLとか独自ドメインを入手してサーバーを立ち上げることができるものなの?

 

D: 僕は実際に個人で「Davidea.st」というドメインを所有していて、とっても誇らしく思ってるんだ。そうだな…Firebase Hostingを使うと、どこのドメインプロバイダーのものでもいいんだけど、例えばGoogleドメインを使うのなら、とても簡単だよ。というのもGoogleと連携したサービスを提供したことがあるから。でも、ほとんどの場合、Firebase Hosting上で展開が可能で、プロジェクトネームとか何であれ、その「プロジェクトネーム.firebaseapp.com」というドメインが入手できる。

その状態で、SSL化やout-of-boxも有効になっていて、グリーンロックが自動的に表示されるようになる。それと、WebUIのような機能もあって、そこで独自ドメインを設定したいとなると、基本的にFirebaseは「了解、必要事項をドメインレジストリに登録して、このボタンをクリックすれば、そのドメインがすでに存在しているかどうか確認します」という流れになり、それが完了したら、はい以上。希望のドメイン名が一瞬でセットアップできる。

 

M: それは素晴らしいね。ただ、Firebaseに対しての批判もいくつかあるよね。その多くはスピードに関するものだよ。というのも、常に使用するJavaScriptを何とか減らそうとしていて、基本的で最小限にして、3秒以内でできる限り素早く画面を立ち上げさせようとしているから。そして、批評で言われているのは、Firebaseはかなり大きなボリュームを使用していることだ。それは僕からすると、2つの相反することだなと思う。

で、その問題を解決するためにディベロッパーとして何ができて、そしてFirebaseはどう対処しているの?

 

D: 僕が思うに、ウェブというのはおかしなところにきているんだ。ウェブ上でかなり多くのことをしようとしていて、要はさっきも話に出ていたアプリ的な動きをさせたいとなっている。ここでいうアプリ的というのは、インストール時間にして50メガバイトのライブラリを有していて、WiFi環境かどうか問題ない状態だけど、ウェブとなると、そういったことはありえないことで、ウェブ上で50メガバイトのものなんて絶対にありえない。だから、より多くの機能を有しながら、読み込み速度という基本原理を損なわない、という衝突と対峙している状態なんだ。

そこで、僕がやっているのは「読み込むためにまず最初にする必要があることは何か?」ということを考えるということ。すると、アプリにとって最低限の実行可能な部分が必要になることがわかる。実際、Firestoreのライブラリは、一般的なものに比べると容量が大きい。それはその分機能が多いからだ。要は、ブラウザ上に自分用のデータベースがあるみたいなものだから。ただデータベースとしては、それでもかなりサイズが小さいものだと思う。でも、処理する量は大きい。いや、そんなものは必要ない、例えばコンテンツをユーザーに提供していて、そんなライブラリをクリティカルパスに置きたくないというのであれば、HTMLをサーバー上で使用すれば、JavaScriptのようにHTMLやCSSだけの必要最小限のレイヤーをレンダリングすることができる。

僕が気付いたのは、Firestoreのようなものを実行すると、アプリ上の機能が強化され、読み込みが始まると、リアルタイムでオフラインでも作動するということになる。アプリを設計するということは、ユーザーが利用を続ければ、それだけ機能は強化されるということ。「はい、このアプリは単一のデバイスごとに1回だけ使用可能です」なんて言いたくないわけで、プログレッシブブートストラッピングがアプリには求められることになる。もしウェブの特徴を兼ね備えたパフォーマンスを求めるのであれば。

 

M: 今、アプリ構築を3つに分割するという設計コンセプトに取り組んでいるそうですが、そのことについてもう少し詳しく話してもらえますか?

 

D: 自分が初めて思いついたことだと思ったんだけど、もうやり切ったなと思ったら、他にやった人はいなかったかを確認するものなんだ。そしたら、すでに実践されていて、名前までついていたよ。プログレッシブブートストラッピングとは、ひとつの考え方を指している。アプリ構築に必要最小限なものは、HTMLやCSSだけだった。それがあれば、かなりのことが実行可能になる。そして、それに加えるレイヤーとしてJavaScriptを使うことで、ReactやPreact、Angularなどのフレームワークを使うなどすることで、HTMLやCSSに加えた拡張になる場合がある。

その点では、このアプリがあればデータを受信するたびに作動し、ネットワークから何かを受け取ったら、画面が変化して、ユーザーがそれに反応する。アプリ上のものがよりダイナミックになるんだ。データそのものがどこから届くかは全く関係なくて、アプリ自体はそういうことに依存しないものということ。もし遅延読み込みをFirestoreで使用したとすると、Firestoreでの読み込み準備が整ったら、時間をかけて読み込みを行うという機能が作動することになり、リアルタイムで表示されるような感じで、突然ページ上で何かが動き出すような状態になる。そして、オフラインになると、そのデータはデバイス上にキャッシュとして残る。

 

M: 歴史的にもそうだけど、今まで僕らは一気に全てを読み込めるページをデザインし開発してきたわけだけど、それってあまり意味がないように思うんだ。今までの話からすると、必要としているときに、必要としているように作動する機能だけ使える状態にすれば良くて、必要でなければ全てのデータベースを読み込まなくていいということだと思うんだけど。それはつまり、例えば通知機能が必要ないのであれば、それに関する部分は読み込まないということになるのかな?

 

D: そうだな、いろいろな方法でのコード分割(Code splitting)が今の話のケースには使えると思う。

例えば、アプリを別のルートに分配する場合、自分のホームページのプロファイルコードを読み込みたくないわけだよ。そんなの意味がないからね。必要ないものを含まないことでパフォーマンスを向上させることができるんだ。今の話はそういうことだと思う。Firestoreは必要なんだけど、すぐに必要というわけではない。そういうときに、もし自分のクリティカルパスにFirestoreのJavaScriptを含めてしまうと、アプリそのものを読み込むための時間が長くなってしまう。じゃあ、それを楽にする方法を見つけようとなる。

そこで、段階的にそのブラウザーが処理できるものを読み込ませる。まずはHTMLとCSSから始めよう。で、表示される。そして、それを強化するものとしてJavaScriptを加える。そうすれば、とても簡単な話になる。ということで、僕たちは全ての要素についてこのやり方を目指しているんだ。ただ、もし何か問題が生じてJavaScriptを読み込まなくなっても、それに対応したコンテンツをユーザーが利用できるようになっている。

もしくは、接続がかなり遅い状態にあったとしても、初期コンテンツやJavaScriptフレームワークがある。ただその場合、Firestoreが読み込むのに時間がかかってしまい、タイムアウトが起きたり、読み込みができなかったりということもあり得る。でも、アプリそのものは、それぞれのフォームにおいて利用可能だ。

そこで、僕たちはページ上にこれら3つ全てを取り入れておきたいと考えている。ただ3つのうちの1つに到達しさえすればもう大丈夫という脱出口みたいなものを設けようとしているんだ。ちょっと待って、よし心拍は問題ないけど、雑音があるな。

 

M: それってただ芝刈り機を使っているだけかもしれないね。

 

D: そりゃそうだ。

 

参照リンク : Designing a Progressive Web App with Firebase – Designer vs. Developer #25 – Google Chrome Developers CC BY 3.0)
当記事はクリエイティブ・コモンズ・ライセンス(Creative Commons license / CC license)に基づいて編集しています。

共感いただけましたら、いいね!シェアいただけますと幸いです。

ASOBO DESIGN™ とは

ASOBO DESIGN ロゴ

ASOBO DESIGN (アソボデザイン)へようこそ!デザインの制作に関わることは何でもご相談ください。

チラシ・ポスター・パンフレットや、名刺・ショップカード・DMなどの各種印刷物、看板・ロゴマーク・パッケージデザインまで幅広いグラフィック・広告デザインに対応いたします。デザイン制作だけでなく、印刷から納品まで一貫して対応(※)しており、展示会・キャンペーン・販促宣伝活動等に貢献致します。※一部媒体を除きます

お問い合わせ

デザインの見積もり・制作依頼

SSL カード決済対応 銀行振り込みの他、各種クレジットカードでのお支払いにも対応しています。 デザイン料金はクレジットカード対応

ピックアップNEWS

実用的な折チラシデザイン
書籍「実用的!折りチラシデザイン」に作成したチラシが掲載されました。

チラシデザインが書籍に掲載されました
書籍「タイトルまわりのデザイン表現」にチラシデザインが掲載されました。

チラシデザイン集に掲載されました
書籍「実用的なチラシデザイン」にデザインが掲載されました。

雑誌掲載事例
デザイン総合情報誌「MdN」にWEBサイトが掲載されました。

メディア掲載事例について
インディーズCDの制作ガイドに、デザイナーとしてのインタビュー記事が掲載されました。

インターナショナルファッション誌 "En Vie Fashion Magazine" 内にデザインが掲載されました。

Adobe MAX Japan にて制作デザインが展示されました。

NEWS&PRESS情報一覧

事業概要 / ご利用規約

平日11時〜18時は電話でのお問い合わせも承ります。
050-5243-3791
問い合わせ専用となります。具体的な依頼の進行はメールでのやり取りとなりますので、予めご了承ください。タイミングによっては営業時間内でも応対出来ない場合もございます。その際はお問い合わせフォームをご利用ください。

お問い合わせフォーム