HTML5を使うべき10の理由

プラグイン vs HTML5 それぞれの「適材適所」のエントリーの解説編です。続いてHTML5の判断材料です。同じく10項目挙げてみました。また文章ばかりです。

○スマートフォン向けである(特にiOSも対象)

iOSではPlug-inが排除されているのですから、何の余地もありません。またターゲットをAndroid等のスマートフォンに特化できるなら、HTML5が良いかと思います。Flash PlayerはAndroid OS2.2から対応していますが、パフォーマンスを出すには繊細にチューニングした開発が必要です。
ただし、注意が必要なのは、HTML5で画面を作ったからといって、PCでもスマートフォンでもOK!という訳にはいきません。タッチやジェスチャに対応した画面作りが必要で、AppleのUIデザインガイドラインに従わないと違和感のある画面となります。

○読む/見るコンテンツである

テキストを読む、画像を魅せる、といったコンテンツが中心であれば、あえてFlashじゃなくてもいいのでは無いでしょうか。その画面やコンテンツ間の遷移のエフェクトとしてCSS3のTransitionは、アニメーションとして強力な機能だと思います。

○既存HTML画面にアドオンする

これまでHTMLで作成されたWebアプリケーションで、使い勝手の向上のためにちょっとした機能(例えばドラッグ&ドロップ)を追加したり、フォームへの入力項目をWebStrageから呼び出したい、といった機能であれば、HTML5は非常に効果的だと考えます。

○HTMLを生成/編集する

表現が難しいのですが、Webアプリの目的がブログやCMSのようにHTML自体を編集するようなものであったり、ブラウザやDOM操作を行ったり、というような場合、HTMLコンテンツとの親和性の高さからプラグイン技術よりはHTMLベースで作った方がよいと考えられます。

○検索エンジンに最適化する必要がある

Google等のメジャーな検索エンジンではSWFの内容も解析しインデックス化されますが、やはり世界にはマイナーだったり、古い検索エンジンも存在し、何よりキャッシュされたコンテンツの表示にはFlashやSilverlightはほぼ対応していないのではないでしょうか。

○ブラウザの機能を利用する必要がある

ブラウザのテキスト検索はFlashやSilverlightで作られたコンテンツの内容までリーチできません。画像をブラウザ内からドラッグしてデスクトップに置く、といったこともFlash/Silverlightもできないですね。

○他のサービスにパースされる必要がある

HTMLページ全体を翻訳のためにドキュメント全体がパースされたり、セマンティックなサービスに解析される必要があったり…といった要件があれば、画面全てをHTMLベースで作成しておく必要があります。

○ベンダーのコントロールから逃れる

言うまでもなくFlashはAdobe Systemsの、Silverlightは、Microsoftの製品です。FlashやSilverlightのプラグインのアップデートは、我々のコントロールにありません。昨今は脆弱性対応等で細かなアップデートが多く、そのアップデートが今稼働しているシステムに影響があるかどうか知る術はありません。
また、ベンダーの意向によってロードマップが変更になったり開発が中止されたり、ということが現実的に起こりえます。
一方、ブラウザのアップデートによってJavaScriptが突然動かなくなった…ということも無い訳ではないと思いますが、経験的には少ないように思います。
ただ、ベンダーのサポートが無いというのは不安でもあります。いざというとき、MSDNに入っていればサポートが受けられる、というのはエンジニアにとっては心強いです。

○「先進性」をアピールしたい

不純?な動機に見えますが、コンペとかではこういうことで引っかかったりしますよね。表現や機能的にFlashでできることを、HTML5でもここまでできるぞ!ということで話題になります。

○スキルのあるJavaScriptの開発スタッフがいる

Ajaxでクロスブラウザ開発の経験が豊富であれば、こちらも何の躊躇無くHTML5で取り組む事ができます。

いかがでしょうか。

Related Post

Kii Cloud JavaScript SDKを使ってデータを保存するKii Cloud JavaScript SDKを使ってデータを保存する

本記事はKii Cloud JavaScript SDKを使ってアカウント登録とログイン機能を実装するの続編です。今回は、データをKii Cloud上に保存する方法についてご紹介します。※ユーザーがログインしていることを前提としています。 オブジェクトのスコープを決める ファイルのアップロード含め、ユーザー以外のデータはすべてKiiObjectを使って操作します。また、Kii Cloud上へのデータ保存には、必ずBucket(以降、バケツと呼びます)が必要です。例えばTODOアプリで自分だけのTODO、グループに共有したいTODO、全体に公開したいTODOの機能を実装する場合、それぞれユーザースコープのバケツ、グループスコープのバケツ、アプリケーションスコープのバケツにオブジェクトを保存します(※準備編でも例に挙げています)。

WebフォントをSVGからOTFに切り替えた際のハマりポイントあれこれWebフォントをSVGからOTFに切り替えた際のハマりポイントあれこれ

先日、1年ほど前に公開したスマートフォン向け秀英体見本帳を更新しました!スマートフォン向け秀英体見本帳は、モバイルブラウザを対象としたWebフォントを使った縦組み表現に挑戦したコンテンツです。スマートフォン向け秀英体見本帳はこちらから、推奨動作環境等はこちらをご覧ください。 更新、といっても、見た目はほとんど変わらないのですが、Webフォントのフォント形式をSVGから他の形式に切り替えました。SVGフォントの場合は不具合なく表示されていたものが、WOFFやTTF、OTFに切り替えた場合に表示の不具合が出たりして意外に大変でした。モバイルブラウザでのWebフォント表現のノウハウが少なく、問題が不明で未解決のものもありますが、今回ハマったポイントをご紹介します。 検証端末 今回の検証に用いた端末の端末名/OSバージョン/ブラウザは以下です。 AQUOS PHONE SERIE ISW16SH

Parse.comを使ったサーバサイド実装不要のフロントエンド開発[後編]Parse.comを使ったサーバサイド実装不要のフロントエンド開発[後編]

本記事はParse.comを使ったサーバサイド実装不要のフロントエンド開発[前編]の後編です。前編では、Parseの管理画面と、JavaScript SDKのうちBackbone.jsをベースとしている部分とCollectionの生成に必要となるデータの取得方法をご紹介しました。後編では引き続き、ParseのJavaScript SDKの機能として以下の3つをご紹介いたします。 Parse.User: アカウント管理 Parse.File: 画像をはじめとしたファイルのアップロード処理等 Parse.Promise: Defferedの仕組み Parse.GeoPoint: 位置情報 Parse.User