*本ブログは Atlassian Blogs を翻訳したものです。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2012 年 1 月 18 日、Rich Manalang 投稿 "Modern Principles in Web Development"
最近私は小さな Web アプリをいくつか始動させました。どうやら新規プロジェクトを始めるたびに私の開発理念の調整を余儀なくする新しい何かが起こるようです。今回の記事では最近の "はやり" について触れておきたいと思います。私は Web 開発がアイデアから始まり納入に至る各段階で構成され、優れたアプリの作成方法に関する強い原理に裏付けられているという考えが気に入っています。
私の Web 開発中核原理を以下に紹介します。
- まずモバイル用に設計する (モバイル アプリを作成していなくても)
- シングル ページ アプリを作成する
- 自分で使う REST API を作成する
- 「見た目勝負」は Web アプリにも通じる
ほとんどの開発者は物事の構築方法について独自のルールを持っています。こうしたルールは独断的なことが多いですが、自分のルールなのでそれでもかまいません。それぞれの原理がどのような理由でアプリの構築の中核を成しているかを以下に説明します。
まずモバイル用に設計する
昨年、Luke Wroblewski 氏は「まずはモバイル用に設計」という考えを広めました。この考えが生まれた背景はモバイル Web/アプリの使用率が高まってきたことと、デスクトップ用に設計された多くのサイトやアプリでユーザーがその質の悪さを感じることです。まずモバイル用に設計することでアプリの機能を小さい画面に収めることに注力するようになります。アプリに関する最も難しい決定を初めから行わざるをえません。つまり、機能をあらかじめ提示し、重要な機能だけに絞り込むようになります。
大きい画面用に設計すると余白が多くなるため、そこに機能を埋めたくなります。小さい画面で始める場合、その逆の問題が発生します。少数の機能セットを設計するようになります。機能セットが少数の場合、アプリケーションの中核部分に注力しやすくなります。また、大きい画面用に設計していたときには行わないやり方で、こうした限られた機能を刷新せざるをえなくなります。
この設計アプローチの別の利点として、パフォーマンスを前もって検討するようになることです。現在最も速い Web アプリは何だか知っていますか? Google やどこかの新興企業の最新アプリではありません。それは 空白ページ です。そうです、空白ページも Web アプリの 1 つと見なされます。空白ページに追加していくにつれて動作が遅くなっていきます。モバイル用に設計することで、アプリが膨れ上がるのを防ぎます。アプリを小規模かつ高速にすることができるのです。
「まずモバイル用に設計」に似たアプローチとして、レスポンシブ Web デザイン (Ethan Marcotte 氏の発明) があります。レスポンシブ Web デザインもデスクトップ サイズの Web アプリをモバイル サイズの Web ブラウザーに修正する手段として誕生しました。レスポンシブ Web デザインは、デザイン理念というよりはさまざまなサイズの Web アプリを作成する際の技術といえます。その中核技術は メディア クエリ と呼ばれる CSS3 の機能を使用します。メディア クエリを使用すると、設定したクエリに一致する代替 CSS 規則を適用できます。最も一般的なメディア クエリはブラウザーの "ビューポート" のサイズの決定に使用されます。メディア クエリを使用すると、既存のデスクトップ用 Web サイト/アプリをモバイル向けに活用しやすくなります。
ただし、その影響を理解してからメディア クエリを使用することが重要です。たとえば、アセット (JS/CSS) の多い大規模な Web ページ (つまりサイズの大きい HTML) がある場合、メディア クエリを適用してもモバイル デバイスでのそのページのダウンロード速度は改善されません。
スポンシブ Web デザインは画面サイズに応じて規模を拡大/縮小する必要がある Web アプリを作成することが決まっている場合に使用するのが最適な技術です。レスポンシブ Web サイトの良い例は こちら で参照できます。
シングル ページ アプリを作成する
シングル ページ アプリ (SPA) は新しい概念ではありません。2004 年に Gmail がこの概念を広めましたが、以来あまり導入は進んでいません。一言で言うと、シングル ページ アプリは 1 つのページで完全に動作する Web アプリを指します。従来の Web アプリはページからページへと遷移します。各ページはリモート サーバーで動的に生成されます。通常、ブラウザーに配信される Web ページは比較的静的であり、ページに表示するデータややり取りを処理するプログラム的なロジックはあまりありません。
それに対し、シングル ページ アプリはプログラム的ロジックや計算のほとんどをブラウザーに託します。シングル ページ アプリではサーバーが Web ページを組み立てることは通常ありません。代わりに、Web アプリは基本的にブラウザー上で完全に "実行" されています。ブラウザーとサーバー間の唯一のやり取りは、アプリの実行に必要なデータの交換だけです。これはすべてページの更新や再読み込みなしで発生します。
高速で高品質なブラウザーが出現したことにより、シングル ページ アプリの設計と構築がかつてなく容易に行えるようになりました。過去何年かの間に、Web フレームワークや JavaScript ライブラリがこの新しいパラダイムに対応すべく進化してきました。この点については後でもう一度触れたいと思います。
シングル ページ アプリにより、"リアルタイム" アプリの作成も可能になりました。リアルタイム アプリは生きているアプリであり、ユーザーが操作することなくアプリ自身が更新を行います。ここ数年でブラウザー ベンダーはリアルタイム アプリをサポートする機能の作成に尽力し、リアルタイム アプリの構築を格段に容易にする規格 (Web ソケット) を作成しました。
自分で使う REST API を作成する
自分で使う予定がないのに API を作成しても無駄ですよね? 最良の API とは、目的を持って使用される API です。持っていることをアピールしたいためだけに何かを構築したとしたら、それは何にも役に立たないものです。
REST API 自身、やや偏屈なところがあります。ある API を REST API と呼ぶには一連の厳格な原理に準拠している必要があると信じる人たちがいます。問題は、その原理自体に対してさまざまな意見があるということです。
REST API の背後にある中核原理は何であれ、私が絶対的に従う指針的な原理は、「API は実用的であるべき」だということです。実用的な API とは、汎用的にではなく目的を持って構築されたものということです。
自分で使用するために REST API を構築すべき理由はそこにあります。自分で使用する予定がないのに他人が使用してくれることを期待できるでしょうか?
私にとって自分の REST API を使用するのは、"モバイル優先" 設計の自作シングル ページ Web アプリにパワーを与えるためです。つまり、私の Web アプリは自作の REST API を MVC の M (モデル層) として使用していることになります。これが私のシングル ページ アプリとサーバー間の全データ交換のインターフェイスとなっています。
「見た目勝負」は Web アプリにも通じる
これは私にとっては明白なことです。優秀なデザイナーやユーザー エクスペリエンスを扱う人を見つけるのが困難なのには理由があります。彼らは引く手あまただからです。ユーザーがアプリに最初に触れたときの印象は最も重要なことです。いろいろなことに言えますが、第一印象を最大限良く見せたいと誰でも思うものです。
好むと好まざるとにかかわらず、見た目の優れたアプリは人目を多く引きます。根本的には自分の作ったアプリが優れていたとしてもです。しかし、ユーザー エクスペリエンスが悪いアプリは根本的に優れているとは言えないことも強調しておきます。私たちは開発者として設計とユーザー エクスペリエンスの重要性を軽視しがちです。開発当初の時点からこの点を組み入れる開発者の製品は大成功します。設計が得意でない場合は他の人を見つけましょう。今すぐです。これは見過ごすことのできない原則の 1 つです。
誰にでも意見はある
私の意見は私のものです。私たちは開発者として意見を持つ資格があります。最終的に重要なのは、実装ではなくアプリが創り出すエクスペリエンスなのです。Web 開発は今後も変化していくことでしょう。Web 開発に長いこと携わっている人であれば、同じようなパターンが繰り返されているのが分かると思います。私たちは開発者として進化し続けます。私たちの意見や技術も同様です。私は違った角度で物事を見ざるを得ない状況に置かれることを楽しいと感じるたちです。次回そうした状況になったときにこの記事は書き直さなければいけなくなるかも知れませんね。
皆さんはどうですか? あなた自身の Web 開発原理をシェアしてみませんか?
(翻訳：Go2Group 株式会社)