いわゆる埋め込みプレーヤ機能を提供するときに考慮するポイント
Yusuke KawabataドクセルやYoutubeなど、外部サイト（ブログなど）で埋め込まれるプレーヤを開発するときに考慮するポイントについて、あまり情報がないので思いつくままメモしておきます。
Yusuke Kawabataまず基本構造ですが、プレーヤ部分はiframeタグで呼ばれることを考慮して作る必要があります。外部サイトに埋め込むときだけiframeにするのか、自前サイトに埋め込むときもiframeにしちゃうのか、それはサイトの作りによります。
たとえばSpeakerDeckとかだと自前サイトもiframe利用です。
ドクセルもこの方式を踏襲しています。一方でYoutubeなんかは、自前サイトではiframeは使ってないように見えます。
ちなみにドクセルのiframeの中身はこんな感じ
Yusuke Kawabataさて、このiframeでなんとかするについていくつかの制約が発生します。最近頭を悩ませているものがアスペクト比の問題です。
ドクセルでは、当初のターゲットを既存の（古くからある）スライド共有サービス利用ユーザにしたため、常設のコントロールバーを用意しました。ところがこれが課題となるのです。
Zennでも埋め込み対応時に苦慮されたのですが、埋め込みもとできれいに表示しようとするとアスペクト比が比率であらわせなくなります。
要はどういうことかというと、16:9のスライドがあった時に、iframeのサイズが16:9(+50px)になるのです。これはレスポンシブ時代にはいただけません。CSSで何とかする方法は太古の昔からあるのですが、埋め込み側が工夫して外側にdivタグを一つ用意してCSSをあてるなどひと手間かかるのです。
Yusuke Kawabataそのため、次期プレーヤはオーバーレイ型（SpeakerDeckやYoutubeのように、コンテンツの上に重なる形）にしようと思うのですが、そうすると今度は別の悩みが出ます。
クリックエリアの調整です。今ドクセルではこんな感じになってます。
ここにコントロールオーバーレイを載せるとこんな感じになります。
さらにスライドのサムネを載せるとこんな感じ。もうお腹いっぱいですね。クリックエリアが渋滞しすぎます。
※SpeakerDeckは、コンテンツ内のリンククリック機能がないのですっきりしている。
Yusuke Kawabataあとはデザイン上の表現で大変そうなのは、縦長と横長が混在することくらいですかね。ふつうはスライドなので横長が多いのですが、数％ですが縦長の資料（主にパンフレットやWordで作ったもの）を共有いただくこともあります。
ただ、そもそも論でいうと、投影を意識したスライド資料と、読ませることを意識したパンフレットやWord資料では、文字サイズが違いすぎるので、埋め込みプレーヤとの相性問題があります。（たとえばスライドが見出し28pt,本文16ptだとすると、Word文書は見出し14pt、本文11ptなど ）
であればもうこの際pdf.jsベースのプレーヤにして、拡大縮小も対応すればいいじゃんと思いますよね。pdf.jsはそれはそれで別の問題があります。
- 必然的に元ファイルを公開することになる
- PDFをそのまま読ませるということは、ネットワーク上に元のPDFが流れるので、うっかりさんが消し忘れたプロパティや墨消しのミスが露呈する可能性や、２次流通を抑制したいという公開者の意図がまもりづらくなる。
- 意外とレンダリングバグ多い
- ブラウザのメモリ上でレンダリングするので、画像解像度や、イラレなどで作った網目模様などオブジェクトが多いと簡単にレンダリングが失敗します。しかもブラウザ依存なのでiOSだと問題ないがAndroidだと正しく見れないという事態が発生します。現にpdf.jsで実装された決算報告書閲覧サイトなどではこのように端末によってレンダリング結果が違うという問題がでています。
Yusuke Kawabataだいたいお悩みについては書いたので、現状のドクセルの実装についてもう少し解説します。embed.jsについてです。
埋め込みスクリプトというものを提供していまして、どこもそうなのですがiframeそのままだとレスポンシブ対応が難しかったりするので、その対応をJSで提供しています。
このJSは、１ページに複数埋め込まれることを前提に、特定のdivタグを検索し、iframeをロードするという処理と、ロード完了時及びWindowのリサイズ時に再度サイズを計算してiframeのサイズを変えるというシンプルな役割を担っています。
ただ、JSに対応していないCMSも多いので、その場合はiframeで埋め込んでいただくことになりますね。
Yusuke Kawabata次はoEmbedとTwitter player cardsについてです。oEmbedはブログなどが埋め込みコンテンツを自動で検知できる仕組みです。
ドクセルの場合このようなURLでJSONが返ってきます。プレーヤのようなiframeコンテンツを出したい場合にはrichを選びます。
似たような仕組みで、Twitterでもタイムライン上でそのまま再生できる機能があります。Player Cardsという機能です。
<meta name="twitter:card" content="player" />
<meta name="twitter:player" content="https://www.docswell.com/slide/LK7J5V/embed?mode=twitter" />
<meta name="twitter:player:width" content="620" />
<meta name="twitter:player:height" content="405" />
ただこれは賛否がありまして、Twitter内で再生できる！便利！すごい！みたいな声と、PlayerCardの場合、クリックするまでサムネは小さい版が利用されることから、画像をでかでかと表示してくれたほうがありがたい派に分かれるようです。
そのため、ドクセルではページ側のシェアボタンやURLのシェアでは、Playerタイプ、埋め込みプレーヤ内のシェアボタンやURLの後ろに/3などページ名を付けたときは画像のシェアと使い分けて提供しています。
Yusuke Kawabata最後に、メッセージ通信です。iframeで提供していますが
- キーボードの左右キーでページ送りしたい
- 5ページ目から表示したい
みたいな要望に対応するために、iframe間でpostMessageを利用しています。
これで、親ページからiframeに右へ、左へ、Nページ目へという情報を渡すようにしています。
Yusuke Kawabataあーあとおまけに。そもそもプレーヤじゃなく画像を縦に並べてくれよスマホ時代だし。というお声も一定あります。
これはもう、「風情」の問題だと思っているので、ドクセルに広告を入れる時が来るとすれば、広告とセットで縦に画像をだらだら表示する閲覧モードも提供しようと思っております。iframeには対応しにくいんですけどね