基本構造は理解していますか？

初心者WEBデザイン？
【基本構造の理解】について


WEBサイト制作を勉強しようとした時に、まず思いつく事が、HTMLを勉強しよう。　と、誰しもが思うはずですが……　　ちょっと待ってください。

初心者がいきなりHTMLを勉強しても、おそらく上手くは行きません。
もちろん、HTMLを勉強する事は間違っていませんが、その前にブラウザーで表示されているHTMLや画像の構成や理屈は理解していますか？

最近は、HTMLやCSSをよくご存じのクライアントさんも大勢いるのですが、大元の基本構造を理解していない、あるいは間違って覚えてしまっている為に、ミスを犯すシーンを良く見かけます。

例えば、サイト上で使用する画像とHTMLとの関係は？
よく見るHowTo本では、「画像はimgフォルダーに入れて使用しましょう」と書かれています。もちろんこれは間違いではありませんが、少々言葉が足りません。（詳しく書くとややこしくなるので書きませんが）

また、外部からのプログラムをサイト内で利用する場合や、リンクと言う考えかたなど。

HTML以外にまず「HTMLを表示させる為の基本的な構造」を理解していないと、制作途中で躓いた時に、その原因究明に時間が掛かっていまいます。

例えばよく見かける、画像が表示されない状態になった時に、画像が表示される構造と条件を理解していれば、原因を突き止める事は容易ですが、その基本的な事を理解していないと「どうしてそうなっているのか」という簡単な事も解りません。原因が付きとめられなければ、修正も出来ません。

昨今は、情報が氾濫していて、HTML関係の記述テクニックや解説サイトが多数ありますが、WEBページの基本的な構造を解説したページは意外と少ないです。しかし、さほど難しい事でもないし、（だから見落とされがちなんですが）HTML関連の書籍の最初の方に必ず、その手の内容が記載されているので、読み飛ばさずに、最初からきちんと読んで理解することをお勧めします。

この部分の理解力いかんでは、その後の勉強の速度に違いが出る事があるので、じっくり勉強しましょう。

ターゲットブラウザー について

初心者WEBデザイン？
【ターゲットブラウザー】について

これは、殆どプロの領域なのですが、特定のブラウザーを決めて、そのブラウザーに対して正確に表示される為のサイト制作を行う。つまり、制作の基準となるブラウザーを決める作業の事です。

アマチュアであれば、今使っているブラウザーでの表示が出来れば、とりあえずOK？なのでしょうが、現在のインターネット環境には、複数のブラウザーが存在しており、必ずしも自分（制作者）と同じブラウザーでサイトを閲覧してもらえる訳ではありません。

そこで、閲覧するブラウザーを幾つか決める、つまり「ターゲットとするブラウザーを決定する事」を「ターゲットブラウザー」と言います。

本来は、閲覧される可能性のあるブラウザー全てをターゲットブラウザーとしたいところですが、何しろ、ブラウザーは各ヴァージョンによって、その仕様が変わるので、同じブラウザーでも、ヴァージョン違いで表示が全く変わる事は珍しくはありません。

つまり、全てのブラウザーを網羅する為には、各ブラウザーの全てのヴァージョンを揃えないといけません。
また当然ですが、元になるPCのOSによっても、違いが発生しますので、例えばWinとMacでは同じブラウザーの同じヴァージョンを使っていてもそれは「違うブラウザー」となります。

そう考えると、全てのブラウザーをターゲットとする事は現実的ではない。と言う事が解るかと思います。

では、どうしたら良いのか？
そこで登場するのが【ターゲットブラウザー】という考え方です。つまり特定の方法や、基準を用いて、ブラウザーを選定します。

選定方法で最も多い方法は、ブラウザーシェアによる選定方法です。
これは、インターネットで使われている、各ブラウザーのシェアの多いモノから順に選ぶと言うやり方です。

下の画像は、アクセス解析サービス「StatCounter」（アイルランド）が提供する「StatCounter Global Stats」より日本のブラウザシェアの統計グラフを掲載しています。

http://gs.statcounter.com/#browser-JP-monthly-201106-201206

これを見て頂ければ、IE（Microsoft Internet Explorer）が最も多いブラウザーである事が解ります。
次点としてFF（Mozilla Firefox）。僅差でCr（Google Chrome）が続きます。

この状況を見る限り、ターゲットブラウザーは、IE・FF・Crなどを選定しておけば、大多数のユーザーがカバー出来るようになります。

この統計は、ブラウザーのヴァージョンは明記していないので、あくまでブラウザーの種類別という大雑把な括りですが、ターゲットブラウザーを選定する目安としては、とりあえず十分だと思います。

別の選定方法もありますが、これは初心者向きでは無いので、またの機会に。

また、先日のモニターサイズと同じで、こちらもブラウザーのトレンド？があるので、1年に一回ぐらいは、ブラウザーシェアの動向は確認しておいた方が良いですね。

いずれにしても、WEBサイトを制作するのであれば、複数のブラウザーで、そのサイトがどのように見えるのかと言う事ぐらいは確認する必要がある。　というお話です。

サイト幅につてい

初心者WEBデザイン？
【サイト幅】につてい

たとえプロでもアマでも、WEBサイトを作る上で、一番最初に決めなければならない事があります。
それは、サイトの画面幅です。

サイト制作以前にデザインを起こすにしても、まずサイトの幅を決めない事には、デザインも作れません。

では、一般的にサイトの横幅は決まっているのか？
これが、具体的な数字は決まっていないと言うのが現状です。
（大まかな横幅はある程度決まっていますが。）

で、基本的にサイトをデザインする上での方法として、2種類の方法があります。

固定レイアウトとリキッドレイアウト

固定レイアウトとは、サイトの横幅を固定して、画面の大小にかかわらず、常に同じ大きさで表示をするレイアウトで大多数のサイトで導入されています。

リキッドレイアウトとは、サイトの横幅を画面（モニター）に合わせて伸縮するデザインで、主に情報系のサイトに多いレイアウトです。代表的なサイトはアマゾンやウィキペディアなどがあります。
これは、固定レイアウトとは違い、幅の指定を画面全体に対する％比率で設定しています。
つまり、モニターの表示解像度に対して自動的に変化する方法です。

どちらもの場合も、元になる最小限の横幅があります。リキッドレイアウトでも横幅に対して常に一定の比率で変化したのでは、画面を小さくした時に、レイアウトがおかしくなるので、変化の最小値を設定してあります。

最近ではサイトの横幅は900～980pxが大体の標準幅ですね。おそらくリキッドレイアウトでも、最小値は900pxあたりの数値を入れているはずです。この横幅であれば、17インチのモニターから、24インチのワイドモニターまで問題なく表示できます。ただし15インチモニターを考慮に入れると、800px程度までサイズダウンが必要になります。

ここ数年のモニタートレンドとして、縦横比が16：9の横長画面（ワイド画面）の液晶モニターが一般化しています。
この横長のモニターだと、今までの固定レイアウトでは、左右に大きな余白が生まれてしまい、どうもデザイン的に見栄えが悪い場合があるので、リキッドレイアウトが少しずつ増えている様です。ただ、リキッドレイアウトは横に伸びる性格上、画像の配置やテキストの長さなどに神経を配らないと、見た目が悪くなりリキッドレイアウトの良さが失われてしまうので、注意が必要です。

まぁ、これはあくまで2012年現在の話なので、5年後には21インチモニタが普及サイズになっていて、画面サイズも1200～1300pxになっているかもしれません。これは時代の流れなので、仕方がありません。
そう言った情報を集めて、日々何がベターなのかと言う事を自分の中に基準として作っておく事が、デザインをする上で必要になってきます。

初心者WEBデザイン

それ行け初心者　WEBデザイン

ブログの連載ネタの一つとして、WEBデザイン？の初心者向け講座的な内容をやっています。

テクニック的な部分は少なめにして、むしろ概論や構造などが主体になるかな。
例えばHTMLにしても、CSSにしても調べる気があれば、今のネット社会で、調べられないことは殆ど無いので、明確な答えが解る場合はネットで探して頂いて、どちらかと言うと、答えが曖昧な事についてお話して行こうかと思っています。

さて、と言うことでWEBサイト制作に必要な知識と言うのはどのくらい必要なのか？下記のリストをご覧ください。

このリストはWEBサイト制作に必要な知識です。もちろん専門知識もあるので、全てを覚える必要はありませんが、最低限でも必須項目ぐらいは、理解しておかないと、トラブル対応が出来ないので、最低限の概念として覚えておけばいいかと思います。


WEBサイト制作に必要な知識。

※は必須
▲概念として必要

言語
HTML※
JavaScript▲
CSS※
cgi▲
php▲
Mysqlに代表されるデータベース

ソフト
画像加工ソフト※
オーサリングソフト※
FTPソフト※

ハード
WEBサーバーに関して※
ドメインに関して※
WEBメールに関して
インターネットに関して
データベースに関して


ざっと見て、これだけの事を理解していないと、WEBサイトの制作は難しいです。
もちろん全てを覚える必要はありません。あくまで概念として、「これはどういったことなのか？」という事を覚えておく程度で問題ありません。

正直なお話、これだけ覚えるにはそれなりに時間とお金が掛かるので……
とわ言え、あくまで初心者向け？の内容なので、出来るだけ簡単に説明したいと思っています。

WEBで使用する画像の種類 今さら……第38回

今さら聞けないネットのあれこれ。
今回は
「サイトで使用する画像の種類」
についてお話します。


重要度：★★★★
難易度：★★★



サイト制作で使用する画像は大きく別けて、GIF・JPG・PNGの3種類があります。

当然3種類とも特徴があり、それぞれに適した使用目的があります。

詳しく話せば、小一時間は話が出来るほど、実は奥が深い話ですが面倒なので、ざっくり判りやすくお話します。

後ほどサンプル画像をよく見ていただければ、判ると思いますので、簡単に説明します。

GIF画像
主に画像変化の少ないイラストなどに用いる。(グラデーションが多用されていると、問題あり）

短所
表示色数が最高で256色しかないために、写真などの保存にはあまり向かない。
またデータ保存の方法により、グラデーションの表現が弱く、綺麗に表示できない。


JPG画像
主に写真などの色数の多いものや、グラデーションが多用された画像に用いる。

短所
JPGは保存を繰り返すと、データの劣化が進み画像が荒れる特性を持つので、可能な限り保存を繰り返さないようにする。また、広い面に単一色（バックグラウンド等）が適用された画像などでは、極所的に画像の荒れが起きてしまうので、注意が必要。


PNG画像
イラスト・写真など特にデザインを選ばない。また画像の透過※1も出来るので、WEBには非常に向いている形式。

短所
JPG のように画像劣化が起きない分、綺麗な画像を制作できるが、その反面ファイルサイズが肥大化してしまうので、使用する場合は注意が必要。


ざっくり説明すると以上のようになります。

実際、私の場合は複数の保存データを作って、どれが最適か？という作業をします。
まずは、画像の劣化を確認して、その上でファイル容量の軽い（少ない）画像を選びます。

1.複数のフォーマットを見比べて、劣化の少ない画像を選ぶ。
2.選んだ画像のファイル容量の少ない画像を選ぶ。

特殊な使用目的、またはどうしてもその画像フォーマットでなければならない場合以外は、上記の方法で、画像を選定しています。

まぁ、基本的に綺麗であれば、良いとは思いますが、あまり画像容量の多き画像は、表示に時間がかかったりするので、気を付けてください。


サンプル画像　どの画像も　画像サイズ　横400　縦300px　で制作してあります。

写真をベースとした各種フォーマット画像

GIF　128色
容量：38.2 KB

解りにくいかもしれませんが、おでこ付近の色がグラデーションでは無く、段階的にトーンを配置している様になっています。

 JPG 60%圧縮
容量：9.15 KB

WEBで使用する一般的な圧縮率60％の画像。
全体的にシャープ感に欠けるぼやけた感じ。
しかし、画像容量としては非常に軽くなっている。

PNG-24

容量：163 KB

JPGに比べて約16倍という非常に容量のあるデータ。
しかし、画像の劣化は少なく非常に綺麗な仕上がり。















イラストをベースとした、各種フォーマット画像

GIF　128色
容量：45.6 KB

赤のグラデーション部分が段階的なトーンに変更されている。
また画像容量も、肥大化している。

JPG 60%圧縮
容量：28.1 KB

写真同様、全体にぼやけた感じでの仕上がり、また【JPG】と書かれた文字の脇付近で画像の劣化によるバターンが確認できる。

PNG-24
容量：163 KB

写真の時と同様、綺麗な画像だがやはり容量はかなり大きい。














それぞれの、画像の中から、使用する画像を選ぶとすれば、ここはやはりJPGの圧縮率を上げた画像（80％圧縮）程度を使用する事がベターだと思う。

もちろん、画像の綺麗さを強調する必要なサイトであれば、やはりPNGを選択するだろう。
また、今回のサンプルはグラデーションのキツイモノを選んだので、GIFの出番はありませんでしたが、シンプルなイラストの場合は、やはりGIFが一番良いです。

このように、使用する画像の構成によって、フォーマットを変える事で、より快適で綺麗なサイト制作が出来ます。


透過※1
PNGは、画像そのものを透過させる事が可能な形式で、特殊な効果を使いたい時に、重宝する形式です。ただし。透過PNGはファイル容量も大きくなるので、扱いは十分に検討してかが良いでしょう。

無料の画像加工ソフト 今さら……第37回

無料の画像加工ソフト　今さら……第37回

今さら聞けないネットのあれこれ。
今回は
「無料の画像加工ソフト」
についてお話します。

重要度：★★★
難易度：★★★

最近はサイト管理もCMSなどを使って、ユーザーが変更・更新を行えるシステムが増えています。また、ユーザーの中には、HTMLやCSSを理解している方も数多くおられます。しかし……　サイト内で使われている画像を加工しようと思った時に、画像加工ソフトが無い為に、困った。というお話を伺います。

そこで調べたのですが、今はフリーソフトで高機能な物も数多く出ているので、それらを試すのもよいでしょう。

http://freesoft-100.com/pasokon/viewer.html

http://www.solapane.info/

上記の2サイトからそれぞれの加工に特化したソフトを3～4本選べば、おそらくフォトショップと遜色のない加工が可能になるはずです。

また、最近はオンラインでの画像加工サービスも出てきているので、ソフトをインストールする必要が無いものもあります。

そう言った、サービスを利用する事で、高価なソフトを購入しなくとも、綺麗な仕上がりの画像が加工できるようになります。

Facebookアプリページのスクロールバー

フェイスブックはすぐに仕様を変更するから……

先日、アプリページのスクロールバーを消せない……
と記事を書きましたが、どうやら消す事が出来ました。






下記のコードを</body>の直前に書きます。


<div id="fb-root"></div>
<script>
(function() {
    var e = document.createElement('script'); e.async = true;
    e.src = document.location.protocol + '//connect.facebook.net/ja_JP/all.js';
    document.getElementById('fb-root').appendChild(e);
}());
window.fbAsyncInit = function() {
    FB.init({
        appId: 'アプリID',
        status: true,
        cookie: true
    });
    FB.Canvas.setAutoGrow();
};
</script>



これで、先日まで苦労？していたスクロールバーともオサラバ出来ました。

普通に制作すれば……

実は、アプリページ内にシェアボタンを設置すると、スクロールバーが表示されます。
どうも、シェアボタンで使用している、FB.Shareのjavascriptが絡んでいるようで、今回もお手上げ……

しかし「いいねボタン」であれば、スクロールバーは表示されないので、いいねボタンを使えば、問題ありません。

現在フェイスブックとしては、シェアボタンは正式に対応していないボタンなので、いいねボタンに対応させる為の嫌がらせ？のように見えてしまうのは、私だけ？

まぁ、そんな事を言っても、この方法もいつ使えなくなるかわからない。
そう、facebookは簡単に仕様変更を行って、「変えたから、宜しくね！」と言って終わらせるからなぁ。

しかも技術関連のレポートは翻訳しないし……
仕様の変更はかまわないけど、もう少し情報をわかりやすくアナウンスしてほしいもんです。

やはりconcrete5は手ごわい

久しぶりにconcrete5のデザインテンプレートを作ったけど……

やっぱりconcrete5は特殊ですね。
通常だともう少し簡単に作れるはず？だと思うのですが。

色々なCMSを使ってみましたが、運用面ではconcrete5は非常にいい。
優れたUIのおかげで、新規ページを作るのは、非常に楽ですが。

そこにたどり着くまでが結構大変ですね。
パッケージのインストールは、他のCMS同様に簡素化されているので、あっという間に完了します。

しかし、その先が問題。
サイトのデザインをオリジナルのモノを使用とすると、少々？イヤ結構厄介です。

CMSを利用しようと言う人が使うのですから、言語に対する知識は多少あるにしても、いきなりphpファイルの扱いとか書かれても、もうこの時点で？？？な人も多いのではと思います。

CMSとして日本ではメジャーな？WordPressでも、最終的にphpファイルでの制作が必要になるので、それほどハードルは高くないのかな？？

それとも、解説ページの造りが悪いのか？
いずれにしても、concrete5のデザインテンプレートは少々特殊？
カナ。

facebookページのスクロールバーを消す。

いまさらの情報で申し訳ないのですが……
どうも、スクロールバーを消すと不具合が、と言うかですね。どうも

FB.Canvas.setAutoGrow();

の仕様が変った？感じですね。
急遽色々と検証した結果、結論は。


スクロールバーを表示させたくないのであれば、iframe内の表示を
横810px　縦1280px以内の収めるしか方法が無いようです。

どうも今回の変更だと、基本画面サイズを超えた場合に、縦のスクロールバーに関しては表示の回避が出来ないようになってしまったようです。

つまり、基本画面サイズ横810px　縦1280pxまでの大きさならば、スクロールバーの非表示が可能ですが、それを越えた場合、必ずスクロールバーが表示されます。

以前であれば、基本サイズを超えた大きさ（殆どの場合、縦方向）はそのままブラウザーのスクロールバーで下にスクロール出来たのですが、現在の仕様では、あくまでiframe内で処理をするようになっている様です。

つまり、iframeの基本画面サイズである横810px・縦1280pxを越えた場合、iframe内部にスクロールバーが表示されるようになってしまうようです。そう、横810px・縦1280pxの内部にスクロールバーが表示されるので、実際の画面は横810pxで制作すると、右側がスクロールバーで隠れてしまいます。

また、CSSを使って強制的にスクロールバーを非表示にすることも可能ですが、それをやると画面が固定されてしまい、結局基本サイズ以上の表示は出来ないようです。（スクロールバーが表示されず、画面サイズは横810px・縦1280pxのままです）
※CSSでの強制非表示は、bodyタグに対して、縦方向のオーバーフローを非表示にする設定。
body{overflow-y: hidden;}

また、</body>の直前に入れる下記のスクリプトで、高さを指定してみましたが……

<div id="fb-root"></div>
<script>
 FB.Canvas.setAutoGrow({ width: 810, height: 1280 });
</script>

1280px以上の大きさにはならない事がわかりました。
つまり基本画面サイズの横810px・縦1280pxは何をどうやっても変更出来なくなっています。

他にも色々とやってみましたが、結論は……
完全にスクロールバーを消したいのであれば、コンテンツを基本サイズ内に収める事。
しか手立てが無いようです。

もし、コンテンツが基本サイズより、大きくなる様ならば、横幅を790pxで制作する事をお勧めします。
このサイズで制作すれば、縦が1280pxを越えてスクロールバーが表示されても画面右側に余裕があるので、デザイン的に崩れる事はないと思います。
（横790pxだと、横のスクロールバーも表示されません）

これに関して、もしかすると、アプリ系の何か？を変更すれば、表示が出来る？？
なんて事は無いと思いますが、いずれにしてもここまで来ると専門外になってしまうので、私には厳しいですね。

この件に関して詳しい方がいましたら、ご連絡ください。
と言うか、誰かこの辺のネタ、書いておらんですかね？？


2012/7/9 追記
どうやら、スクロールバーが表示されてる原因を特定しました。
これで、スクロールバーを消す方法が解りましたので、こちらをご覧ください。
http://hon-web.blogspot.jp/2012/07/facebook_09.html

電子書籍の現状【制作現場の惨状】 今さら……第36回

電子書籍の現状【制作現場の惨状】　今さら……第36回

今さら聞けないネットのあれこれ。
今回は
「制作現場の惨状」
についてお話します。

重要度：★★★
難易度：★★


3.制作の現場
過去2回の記事からわかるように、フォーマット・ハードの多様化を推し進めた結果、現在の電子書籍の制作現場では、大変な事が起きています。

想像してください。一つの作品を複数のフォーマットに対応させ、尚且つそのフォーマットを各種のハードに対応させるべく、数種類の分類を行い、それぞれを制作してゆく……

その作業は、それぞれのフォーマットによって使用する制作ソフト（オーサリングツール※1）が必要になり、フォーマット間の互換性があまり無いので、一つのソフトで一つのフォーマットしか制作できない場合もあります。（複数のフォーマットに対応したソフトもある）と言った具合です。

では、そもそも電子書籍のデータ制作とは、どういった手順で作られるのか？簡単に説明しましょう。

基本的には、印刷用のデータから電子書籍用のフォーマットデータを制作します。

フォーマットの回でお話した、ePub形式のデータであれば、印刷データを制作したレイアウトソフトから、制作する事も可能ですが、他のフォーマットの場合は、それぞれ専用の制作ソフトを使っての作業となります。

しかもその作業は、もう一度、同じレイアウトに組み直す。と言った内容が殆ど。
全くゼロの状態から組み直す訳ではなく、若干の手直し？程度の物から、様々のようでアプリによってかなり変るらしいです。

もう、想像しただけでうんざりです。
一般の方には想像しにくいかと思いますが、この作業でどれだけの労力がかかっているか……

つまり一つの作品だけで、膨大な時間と人員を使っているはずなのですが、実際の販売価格は数百円～とかなり安い。

話が横にそれますが、実は日本では、書籍の値段が欧米に比べて非常に安く設定されています。
その結果、アメリカでは、安い電子書籍の人気が出たと言えない事も無いですね。

しかし、日本ではそうもいきません。
この現状になってしまった原因は、前回お話したように、企業側の独自路線を狙ったが為の失策？と言えるのでは無いでしょうか。

いずれにしても現状では、制作サイドの負担が大きすぎて、先行きが暗すぎます。
せめて、汎用で誰でも制作できるような仕組み（フォーマットとハードの両面）を構築しない事には、大きな流れになる事は出来ないのでは？と思えるのですが、皆さんはどう思いますか？

---

オーサリングツール※1
オーサリングツール (Authoring Tool) は主にプログラムを書かないでソフトウェアや作品を作るためのアプリケーションソフトウェア。ただし、必要に応じて補助的なプログラムを書くことができるものが多い。
グラフィックツール、音楽ツール（DTM系）、出版系（DTP用）、ウェブサイト制作や運営管理に用いるWebオーサリングツール、ゲームやスライドショーなどの制作に用いるマルチメディア系、DVDソフトの制作用などがある。
出典：Wikipedia

電子書籍の現状【ハードにつてい】 今さら……第35回

電子書籍の現状【ハードにつてい】　今さら……第35回

今さら聞けないネットのあれこれ。

今回は

「電子書籍のハードウェア」

についてお話します。

重要度：★★

難易度：★★

2.ハード（リーダー）

先日発表された、Googleのネクサス7もそうですが、現在電子書籍の閲覧が可能なハード（端末）は、キンドルの様な専用器だけではなく、スマートフォン・タブレット・PCブラウザー・PC専用アプリそして携帯電話（フューチャーフォン）と言った状態で、まさにカオスです。

これは、我々ユーザー側から見れば、非常にありがたい事のように思われますが、実はそうでもないのです。

前回のフォーマットと同様に、あまりに多様化してしまった為に、電子書籍のデータを制作する製作者側に、多大な負担がかかる状態になっているのが、現状です。

キンドルの様に専用端末であれば制作するデータは1種類で良いのですが、複数のハードに対応しなければならないデータを制作することは、時間も労力も非常にかかります。

何故、この様な状態になったのか？

じつは、この問題の一つとして、出版社が電子書籍を販売しようとしたからという事が考えられます。

では、出版社が電子書籍を販売することが、何故問題なのか？

元々、出版社は書籍を販売することが仕事ではなく、書籍を制作することが仕事です。

本来であれば、書籍データを制作して、そのデータを販売店（アマゾン等）に配布すれば問題は無いのですが、インターネットの世界では、そうした販売も自社行うことが可能です。

企業としては、自社で販売できるデータを持っているのであれば、販売店にデータを卸すよりも、そのまま販売した方が利益率が高いので、当然自社で販売しようと考えます。

しかし、ここで一つの問題が発生します。

アマゾンのように、自社で独自のハードを開発できれば良いのですが、普通の出版社にそのような技術はありません。そこで、最も簡単なWEBブラウザーを利用した専用のビュアーソフトを利用すれば、簡単に自社で電子書籍の販売が可能になります。

ビュアーソフト自体は、ソフトメーカーから、FlashやPDFをベースとしたものが販売されているのでそれを活用すれば、抵コスト・短期間で販売体制が整います。

また、最近ではWEBブラウザーベースのビュアーソフトも登場しているので、比較的簡単に出版社自体で電子書籍の販売を行うことが可能になりました。

このことが、現状の複数ハードへの対応という、非常に厄介な状態を生み出しているのです。

つまり、既存技術の流用による、小額投資で自社の製品を販売し、尚且つ独自フォーマットを使用する事で、顧客の囲い込みも出来る。と言うまさに出版社には濡れ手に粟の状態を作り出したことになります。

しかし、この状態は、大きな問題を孕んでおり、それが現在の電子書籍マーケットに暗い影を落としています。

それは、汎用性の高いビュアーソフトを用いたために、ハードへの対応を迫られると言う状態に陥っていることです。

専用端末での閲覧で、あればその端末に合わせればよいのですが、汎用性の高いシステムゆえに、複数の端末（ハード）への対応をしなければならないと言うことです。

タブレットで読める本が、スマートフォンで読めない。と言ったことが本来であれば、当たり前のはずですが、それでは売り上げが落ちる可能性があります。

そこで、本来は読めないはずのスマートフォンで読めるように対応したプログラムを利用することになります。当然そのプログラムはスマートフォン専用に開発されているので、電子書籍のデータもまた、それ専用のものを用意することになります。

また、対応するハードも、年々増えてその画面表示サイズや、基本OSによって仕様が変ります。

そうした、ハード全てに対応する状況を作り出さなければ、売り上げが確保出来ない、あるいは顧客を囲い込めない状態になっている。と言うのが現状です。

これほど急速に普及したハード市場に追いて、公平なサービスの提供は必ずしも必要なのでしょうか？

アマゾンのキンドルが何故、アメリカであれだけ売れているのか、もう一度検証してみる価値はあると思うのですが。

電子書籍の現状・【フォーマットについて】 今さら……第34回

電子書籍の現状・【フォーマット】　今さら……第34回

今さら聞けないネットのあれこれ。
今回は
「電子書籍の現状」
についてお話します。

重要度：★★
難易度：★★


Googleがネクサス7を発表して、アメリカではアマゾンのキンドルキラーのように言われていますが。
日本での発売は未定ですね。
キンドルについても幾度となく、日本発売の噂が流れていますが、未だに発売される様子がありません。
それは、何故なのか？　一言でいえば日本の電子書籍を取り巻く環境が特殊だからだと言えます。

と言う事で、数回に分けて日本国内における電子書籍の現状を、独断と偏見で語ってみたいと思います。

その1回目は、電子書籍のフォーマットについて、お話します。

1.フォーマット
なぜに共通フォーマットにしないのか？
共通フォーマットを採用すれば、色々なメリットがあるはずなのに、何故共通フォーマットを採用しないのか？

元々、電子書籍には、ePub（イーパブ）※1という世界標準のフォーマットがあります。
このフォーマットは、アップルが採用している正式な電子書籍のフォーマットでもあり、アマゾンの使用しているフォーマットの基本でもあります。
（アマゾンのフォーマットはePubをベースとして独自のコードを追加したモノです）

世界的に見てもこのePubが、一般的には電子書籍の基本フォーマットとなっています。
しかし日本国内ではこのePubを使用した電子書籍というのはほとんどありません。

なぜなら、このePubフォーマットのデータファイルは基本的に、端末にダウンロードし保存してから閲覧するタイプになっているからです。
（もちろんダウンロードせずに閲覧することも可能ですが）

ダウンロードするということは、いつでも好きな時に本を読むことができます。しかしその半面販売店もしくは出版社は一ユーザーにつき一回しか課金が発生しません。

これでは出版社としてはあまり旨味がありません。また、ダウンロードしたデータをファイル共有ソフト等を使用して、ネット上に流出てしまう事も、ePubを使用しない要因の一つと考えられます。

そして、おそらく最大の理由として、ePub形式のデータは小説や、論文等のテキストを中心としたシンプルなレイアウトの書籍には向いているのですが、雑誌などの写真を多様したものや、
雑誌の見開きのように複数ページにわたる表現が苦手です。
つまり、見た目がシンプルで凝った表現には向かないデータ形式なのです。

日本の場合、広い意味で書籍とは、雑誌や漫画などが含まれます。
書店を見ていただければ、判ると思いますが店舗の売り場で、雑誌や漫画、コミックと言った売り場は店舗面積の1/3程度の広さを占めているかと思います。
つまり、それだけ雑誌などが売れている。ということになります。

出版社が電子書籍をはじめようと思ったときに、真っ先に考えることは、
「売れるコンテンツを作る」事です。となれば、自然と雑誌の電子書籍化を考えるはずです。

そのときに、見た目の悪い雑誌は売れないと判断する事は、容易に想像できます。
となれば、必然的にePubフォーマットでの電子書籍化は、せずに独自のフォーマットでの制作を検討することは、自然な事でしょう。

複雑なレイアウトには向かない事が、ePubフォーマットでの普及の妨げと言える大きな要因かも知れません。

もちろん、シンプルなレイアウトに変更してePub形式で制作することは、可能なはずですが出版社はより高い付加価値を商品に添加して、単価を上げることが出来れば、そちらに方が良いに決まっているので、当然の対応と言えます。

また、電子書籍を制作する際に雑誌用に制作したデータを流用して制作できるように出来れば、わざわざ電子書籍専用のフォーマットで制作する必要も無くなり、コストも下げられる。と考えるはずです。

しかし、実際はそう上手くはいきません。
制作に関しては後日詳しく説明するのでそちらをごらんください。

いずれにしても、現状の電子書籍を取り巻く環境は、日本に限ったことではなく、世界的に観ても、複数の電子書籍フォーマットが存在して、フォーマットの統一などと言うことは、むなしい絵空事のようになっているのが、現状なのです。

---

ePub形式
EPUB（イーパブ）は、電子書籍の規格の1つである。米国の電子書籍の標準化団体の1つである国際電子出版フォーラム (International Digital Publishing Forum, IDPF) が普及促進している公開された仕様の電子書籍用ファイル・フォーマット規格である。「EPUB」は"Electronic PUBlication"の意味を持ち「epub」「ePub」などと表記される場合もある。そのオープン性と単純さから、対応する電子書籍のハードウェアやアプリケーションソフトウェアは多く、英語圏での電子書籍用ファイルの標準規格となっている。　
出典：wikipedia　EPUB